Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1
- Date: Wed, 10 May 2017 08:30:24 +0300
- From: Joni Eskelinen <jonieske@xxxxxxxxx>
- Subject: Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1
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
> 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
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
>> 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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple