On 10.5.2017 0.48, Andrey Repin wrote: > 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. > Thanks for the pointers! I'll have a look if there's any added benefit.
>>> 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). > Arguments are tested whether they're local paths and only then converted. >> 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? > Sorry but i fail to see your point. The whole rationale of this tool is to avoid console, to provide simple point and click interface for users to invoke shell scripts. >>>> 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 <directory> && ./<filename>' > > So, you're intentionally changing execution environment? > Yes exactly. This is by design. Typical use case is that a script performs something in its containing diretory, ie. compile or generate something relative to its location. >> 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. > Not necessarily but generally yes, script's directory is always the place it has been invoked. This is the case when you double click it from Explorer or drag & drop something to it. If one has more specific needs, then there's the usual tools to accomplish that. >> 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. > There's no way to make everyone happy, isn't there? :) Luckily this tool is open for forking and i welcome you to open suggestions at https://github.com/sop/cygextreg/issues. - Joni -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
