X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=klK3/HQdEMKx3hoQ
	QIOAXoHzc+4dvMrCItqYHrfJGKVgXzDbJ/RKDMvX/MtjKOu5pZGrW/qjTJmJ8Cxl
	Iasx41gWkSrBHAfRPPm2aGkmaYhPKUdvYZu9Mx4PSFQ1SDRbUIuHdDTXu5HmoDsX
	WXbe68TnsLNIt+nfde/1gd9BkME=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=8ceLj5HlOGEZNa1ngVip4P
	xwf5I=; b=Qy7KNxwjzsoI+mpZSNFJbDxmgOjBIYXNliqEF7mThuhTIdn0ndlOGy
	xIi1CjrNRhcaHgAzBa3yMMIe8aTe70PcYrRqp4KwGtX+dtNCl50G5Hd/AK0RvDVR
	HOAP746x3/G0XPu8GdjD/MwB5aONsesqFbLE4ET52k91OyhSREVsk=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=drag, TCC, perception, tcc
X-HELO:	mail-lf0-f53.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=X8Pf7v4tl+uKcjZBlzl1IQMwDkZzZluYvRvT/Z8hiVE=; b=BH+5WcKtOOfbDKp9zJj71AJLgvtO3pTaVEOUdVndpzq1fnOLKYn2mOnKdp0sZ5ceUG QgZlsYlPTOOs4xalOKLHEf3OkoWiWUGcpA3YeYNMB4IYAS/PlNV85BqCI09ME7al7ccK axI4AfD2UH6rN00XpMI5OiRPwq2Q/I93CVQFOx+/zK+FepaqM1ZW46v8bS7pyCIoaeX/ Bf9MDjHnang/do8MDB5c7suRaVG9wu8c2M6RRvhZH0gnzPlqgdNA9ojnssXN7nZWAJQ0 erS4GHtoZHLA7iVewxuZ6QcpDwc0I07x191ZQRFmERbX+I1fewN/Cen7W7T2wDvp0kCL GhWg==
X-Gm-Message-State:	AODbwcBbMiHAz5jKohWExIxRrJe5oW0v7Z3vVZdD853cdaEIXYYK7J30 7snUaR0txKGsRp54GHs=
X-Received:	by 10.25.163.148 with SMTP id m142mr2189645lfe.22.1494394225201; Tue, 09 May 2017 22:30:25 -0700 (PDT)
Subject:	Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1
To:	cygwin AT cygwin DOT com
References:	<announce DOT 131486df-0b2e-a6d7-9840-21ecd08755a9 AT gmail DOT com> <1351717921 DOT 20170505141750 AT yandex DOT ru> <c9aa6066-6eb4-4c33-7f65-7dd1c34203e1 AT gmail DOT com> <17641936 DOT 20170510004807 AT yandex DOT ru>
From:	Joni Eskelinen <jonieske AT gmail DOT com>
Message-ID:	<c12c96a1-75c3-f4ff-61f6-7e92378c9e47@gmail.com>
Date:	Wed, 10 May 2017 08:30:24 +0300
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version:	1.0
In-Reply-To:	<17641936.20170510004807@yandex.ru>
X-IsSubscribed:	yes

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

- Raw text -