[ANNOUNCEMENT] New: cygextreg-1.2.0-1

[ANNOUNCEMENT] New: cygextreg-1.2.0-1

[Joni Eskelinen]

The following package has been added to the Cygwin distribution:

* cygextreg-1.2.0-1

CygExtReg is a utility program allowing to register an extension (eg.
.sh) to be executed in Cygwin by double-clicking a file from Windows
File Explorer or by dragging and dropping files to an icon of a
registered extension.

https://github.com/sop/cygextreg

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

Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1

[Brian Inglis]

On 2017-05-04 01:29, Joni Eskelinen wrote:
> The following package has been added to the Cygwin distribution:
> * cygextreg-1.2.0-1
> CygExtReg is a utility program allowing to register an extension
> (eg. .sh) to be executed in Cygwin by double-clicking a file from
> Windows File Explorer or by dragging and dropping files to an icon of
> a registered extension.
> https://github.com/sop/cygextreg

Are there any good sources of freely redistributable icon sets from 
windows systems or launchers for Unix utilities e.g. gnome, mate, 
pcmanfm, etc.?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1

[Brian Inglis]

On 2017-05-09 00:30, Joni Eskelinen wrote:
> On 4.5.2017 18.48, Brian Inglis wrote:
>> On 2017-05-04 01:29, Joni Eskelinen wrote:
>>> The following package has been added to the Cygwin distribution:
>>> * cygextreg-1.2.0-1
>>> CygExtReg is a utility program allowing to register an extension
>>> (eg. .sh) to be executed in Cygwin by double-clicking a file from
>>> Windows File Explorer or by dragging and dropping files to an icon of
>>> a registered extension.
>>> https://github.com/sop/cygextreg
>> Are there any good sources of freely redistributable icon sets from 
>> windows systems or launchers for Unix utilities e.g. gnome, mate, 
>> pcmanfm, etc.?
> There's a Tango Desktop Project providing a lot of icons with CC
> license. See https://commons.wikimedia.org/wiki/Tango_icons.
> Also i've found Iconfinder to be quite useful. It has both commercial
> and open source licensed icons available. See
> https://www.iconfinder.com/search/.

Thanks for the links - I'll do some browsing.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1

[Andrey Repin]

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.

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

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


-- 
With best regards,
Andrey Repin
Friday, May 5, 2017 14:05:50

Sorry for my terrible english...


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

Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1

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

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

>> 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>'
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.
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).

- 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

Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1

[Andrey Repin]

[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]

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

[-- Attachment #2: cygwrap.btm --]
[-- Type: application/octet-stream, Size: 738 bytes --]

@SET PROMPT=@$S$P$_
@ECHO OFF
ON BREAK REM

IF "%~1" == "--install" GOTO :SETUP
IF "%~1" == "" GOTO :BANNER

SET PATH=%@RTRIM[\,%@PATH[%@FULL["%~0"]]];%[PATH]
SET ENV=%@PATH[%@FULL["%~0"]]env.exe
SET CMDNAME=%@EXECSTR[cygpath.exe -u "%~1"]
SHIFT

"%[ENV]" -- "%[CMDNAME]" %$
REM ECHO Return %?
QUIT %?

:BANNER
ECHO Cygwin script wrapper.
ECHO Usage:
ECHO.
ECHO   %@FILENAME["%~0"] script [parameters]
ECHO   %@FILENAME["%~0"] --install [.ext ...]
ECHO.
ECHO The ".sh" extension is always registered on install.
QUIT

:SETUP

FTYPE unixshell.script="%[ComSpec]" /C "%@FULL["%~0"]" "%%1" %%*
SHIFT
DO EXT IN /L .sh %$
  IFF "%@LEFT[1,%[EXT]]" == "." THEN
    ASSOC %[EXT]=unixshell.script
  ENDIFF
ENDDO

[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


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

Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1

[Joni Eskelinen]

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