From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54167 invoked by alias); 10 May 2017 05:31:00 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 53467 invoked by uid 89); 10 May 2017 05:30:27 -0000 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 Received: from mail-lf0-f53.google.com (HELO mail-lf0-f53.google.com) (209.85.215.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 May 2017 05:30:25 +0000 Received: by mail-lf0-f53.google.com with SMTP id 99so13354802lfu.1 for ; Tue, 09 May 2017 22:30:27 -0700 (PDT) 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) Received: from [10.0.200.185] (87-100-228-90.bb.dnainternet.fi. [87.100.228.90]) by smtp.googlemail.com with ESMTPSA id z18sm340587lja.15.2017.05.09.22.30.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 22:30:24 -0700 (PDT) Subject: Re: [ANNOUNCEMENT] New: cygextreg-1.2.0-1 To: cygwin@cygwin.com References: <1351717921.20170505141750@yandex.ru> <17641936.20170510004807@yandex.ru> From: Joni Eskelinen Message-ID: Date: Wed, 10 May 2017 05:33:00 -0000 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> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00144.txt.bz2 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 && ./' > > 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