Greetings, Joni Eskelinen! > On 5.5.2017 14.17, Andrey Repin wrote: >> Greetings, Joni Eskelinen! >> >>> The following package has been added to the Cygwin distribution: >> >>> * cygextreg-1.2.0-1 >> >> >>> Scripts are executed with bash >> >> This must not be the case, unless explicitly requested. Enough that >> all Windows associations are executed with cmd if you try to >> CreateProcess blindly. Don't copy this mistake. >> > Bash is used as an intermediary shell that executes the script. > Generally a shebang line denotes the actual interpreter. > Bash was chosen because it's bundled with a default Cygwin installation. /usr/bin/env is also in the default install. And I'm using it to run scripts now. See attached TCC wrapper. >> If you want to make it useful, write a thin wrapper over exec() that >> finds out and runs proper interpreter, and support it with options to >> make interpreters happy. F.e. convert $0 to Cygwin path, if >> interpreter don't understand native paths (i.e. dash cringe over >> non-latin1 native paths and I yet to find out why). >> > All native paths are converted to Cygwin equivalents before invoking > bash, That's not the right thing to do. You can't know if a "path" you convert is an actual local filesystem path (except for $0, but even then, it is not always necessary). > ie. $0 as in the path of the file that was clicked from Windows, > and consecutive arguments if some files were dragged and dropped to > registered file icon. > That is, the script shall always receive only Posix style paths, by design. You have a strangely limited perception on the usability of your tool. How about console invocation? >>> in an interactive login shell. >> >> This should be optional. Login shell may cause $(pwd) to change, not >> to mention, it alters environment. >> >>> If the executed script exits with a non-zero code, MinTTY window >> >> This should be optional. >> >>> shall be kept open >> >> This should be optional. >> > Nice suggestions. I've thought to implement per extension options > especially for keeping the window open after completion. > Script is actually invoked roughly as follows: > /bin/bash -il -c 'cd && ./' So, you're intentionally changing execution environment? > with proper escaping applied. So even though user's personal init script > changes the working directory, the script will be invoked in its > containing directory. Which is not necessarily the place where user had it invoked. > I think it's a reasonable default to have bash run this way, since > there's a fair chance that scripts require environmental variables set > in .bashrc or like (eg. $PATH to ruby gems). I'm not in the favor of chances when I'm doing my work. -- With best regards, Andrey Repin Tuesday, May 9, 2017 17:15:35 Sorry for my terrible english...