[ANNOUNCEMENT] New: cygextreg-1.2.0-1

[Andrey Repin]

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 <directory> && ./<filename>'

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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwrap.btm
Type: application/octet-stream
Size: 738 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20170509/66cf9dd9/attachment.obj>
-------------- next part --------------

--
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