Closed igdswzcd closed 1 year ago
Thanks a lot for looking into this! I truly hope that this will be it now for Windows, and that it doesn't break in subtle, unforeseen ways.
I have created a new breaking release just to be sure this change doesn't catch anyone off-guard.
On Windows OS, my colleagues and I conducted tests and found that:
cmd /c app
command can't open apps which are not in the env variables.However,
cmd /c start app
can open all apps exist in registry pathHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
. This is why I addedstart
to open::with() under the Windows branch. And I recommend adding the registry address that represents the available scope to the doc or README (on Mac and Linux it may be other files), so that developers can quickly determine appnames available.Commands like
cmd /c "C:\app.exe"
can also open the application, butcmd /c start "C:\app.exe"
does not work. Finally I found thatstart "" "C:\app.exe"
is effective which "" is said to open a new window, andstart "" app
also works. It is safe and consistent with the previous changes to open::that(), so I added""
as an arg.To avoid the previous issue, I guess some people might pass
start chrome
as the second function param. After adding two args, it can still open the app but will also open a new cmd window, should this situation be taken into consideration?At last, I modified the test code in main.rs. On Windows, you can call open::with() by using
open.exe path -w app
without specifying an env variable.