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:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-type:content-transfer-encoding;
	q=dns; s=default; b=OtXShHKlcEfl0C4ygXWZqCvQgn/Y5t+NRWEeaNZ3NoL
	+uUSOGN43i5e2D73tIJAZIqEcLMJaFgfHNKVVpQkid8/sgUgSoD87Ep6Wx6TTK3+
	p+ufWHu904V6o0oNVvUXcRbSX1Wr2G6rhRSild8H2I6Fe57Dci0l5QJp4f5w61jA
	=
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:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-type:content-transfer-encoding;
	s=default; bh=bb3qfhJT8Ym5EBynuIl2OJ/0EDk=; b=m0RXu546j0aMBvLJN
	hqpWuFQEip06gMDqe4EbgH8SSZPatI8qwkOlYxQBhUkUR/2zCtg2w1trwOJvfm75
	lpvsJqDv5V31vgAI0YXKJpfuCkuK6mm3q4pB4B7rtahkIH09Ws10311jrXgx1SnI
	46tB7KcosiJoLBZGLnIZ9s5ztI=
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.9 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=satisfying, crop, shells, talent
X-HELO:	nm20-vm6.access.bullet.mail.bf1.yahoo.com
X-Yahoo-SMTP:	_oUbE.SswBCQ_d_LvSIk7sZfv6R7Is8n9OVRVjJJh3dhqEgGPCs-
From:	"Michel LaBarre" <michel DOT labarre AT rogers DOT com>
To:	<cygwin AT cygwin DOT com>
References:	<001001d1edf1$a4e1ae90$eea50bb0$@rogers.com> <1C0AE95E-0118-4353-AA77-4D41F1AE9AE1 AT solidrocksystems DOT com> <001a01d1eea9$f7949a90$e6bdcfb0$@rogers.com> <76ec05e9-140a-19cb-942b-698582c3d024 AT gmail DOT com> <001f01d1ef2c$f04af9e0$d0e0eda0$@rogers.com> <20160805152951 DOT GO25811 AT calimero DOT vinschen DOT de> <57A6ED1C DOT 1060402 AT gmx DOT de> <5adee091-78a6-3a3d-5277-efa9e666f84e AT gmail DOT com>
In-Reply-To:	<5adee091-78a6-3a3d-5277-efa9e666f84e@gmail.com>
Subject:	RE: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
Date:	Mon, 8 Aug 2016 20:45:55 -0400
Message-ID:	<000701d1f1d7$642ba6a0$2c82f3e0$@rogers.com>
MIME-Version:	1.0
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id u790kEOv023736

Based on the emails under this thread and other items I found, it seems that anomalies
handling program suffixes within CYGWIN are not new.  It has been proposed that the 
relevant code be re-thought.  I suggest that any rethink consider PATHEXT support.

It may be of no interest for CYGWIN users of pure Posix applications and tools never intended 
to use, or be used by, Win32 programs as has been pointed out within this thread.  Even then,
Windows underpins CYGWIN so its rules percolate up.  

For users who wish to exploit the power of CYGWIN tools and shells to control 
and supplement Win32 tools, to control and configure Windows and Windows subsystems, 
and extensive corporate applications under Windows,  PATHEXT (plus the file associations 
that determine how to invoke the handler for a given suffix) is a part of the bridge.
In a sense, in this case Windows rules, conventions, and expectations percolate down.

CYGWIN addressing Windows program invocation comprehensively once and for all
might help rationalise things and reduce the anomalous end cases that seem to 
crop up while satisfying the needs  of hybrid CYGWIN/Win32 users.

As a novice CYGWIN user, It is quite possible that I misunderstand CYGWIN and that inter-operation 
with Win32 environments is not an objective in which case perhaps somebody can set me straight 
and recommend an alternative.  It could very well be that, as one response to me on this thread 
alluded, CYGWIN's role is to provide the equivalent of an isolated POSIX VM under Windows 
without the VM. Such isolation pretty much excludes Windows developers and integrators and 
begs the question as to why host all this POSIX infrastructure within Windows in the first place
especially now that VM support is pervasive and efficient?

I expect that many CYGWIN users in fact blend CYGWIN and Win32 tools to build solutions.

As a novice CYGWIN user, I was first struck by the variety of offshoots from CYGWIN. 
Presumably, these offshoots satisfy some un-met needs but must result in dilution of talent and effort.
Maybe I should be looking at one of these but my first cursory looks showed that some
common Unix utilities that I find useful were missing but are in CYGWIN which is why I wound up here.

I really hope to not have offended anybody.

Michel



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