DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type; q=dns; s=default; b=NjyL
	+Nqt53HNW7bdZkOa32vj1CsYz+lUq4k1ZCjNegB7LpiYJapcir7auMGWaph1rpkr
	/NLpzunm/U0DgCv88atSRkRKobsLwworKaX174y6TRX/mcMqA/Vr0PHaODAb/Zy4
	wOBGbbLadPO+V/hV1gPIKLKXrrVMKyW6e6xsPZQ=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
MIME-Version: 1.0
In-Reply-To: <001a01d1eea9$f7949a90$e6bdcfb0$@rogers.com>
References: <001001d1edf1$a4e1ae90$eea50bb0$@rogers.com> <1C0AE95E-0118-4353-AA77-4D41F1AE9AE1 AT solidrocksystems DOT com> <001a01d1eea9$f7949a90$e6bdcfb0$@rogers.com>
From: Erik Soderquist <ErikSoderquist AT gmail DOT com>
Date: Fri, 5 Aug 2016 10:43:20 -0400
Message-ID: <CACoZoo0doP455nnL3m0GYgXuUpLuB-p5Za9KeHfs6xmtT8it6A@mail.gmail.com>
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
To: cygwin AT cygwin DOT com
Cc: Vince Rice <vrice AT solidrocksystems DOT com>,
        Doug Henderson <djndnbvg AT gmail DOT com>,
        Andrey Repin <anrdaemon AT yandex DOT ru>, Bill Smith <bsmith AT progress DOT com>
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 4, 2016 at 7:43 PM, Michel LaBarre wrote:
> Well my first foray into the world of CYGWIN mailing lists has been
> a lot of fun so far.

Glad you enjoyed it  :)

> Rather than replying to each respondent, I will try to respond to
> each in one email.  This may be a mistake.

It is, as is top-posting.  Top-posting very badly disrupts the
natural continuity of reading the message.  For some readers, top-
posting alone is justification for a bulk-delete.

> At least people who think I am an idiot will only have one email
> to delete instead of one per respondent.

Idiot?  I doubt it.  Misinformed on some topics, yes, but aren't we
all somewhere along the way?  It is usually quite easy to build a
filter to bulk-delete by sender if needs be.  I'm pretty sure most of
us would still prefer inline responses and multiple message over top-
posting by a wide margin.

> Vince: my perceived difficulty "in reporting an issue or comment"
> has more to do with my not wanting to SPAM an entire mailing list.

As this list is the primary support and ideas tool designated,
posting here regarding CYGWIN is not spam.

> ... ... ... having spent 15 years supporting the same
> KSH/perl/AWK/etc scripts under Solaris and Windows for a few
> clients, using the MKS toolkit which does support PATHEXT, I
> apparently took advantage of that support extensively.

I would consider that in and of itself a mistake; however, I was
burned by PATHEXT in my early days with foo.bat, foo.cmd, foo.exe,
foo.com, and foo.vbs all in the same directory, and all doing
different things, and which one I got seemed to be a roll of the dice
so I started using the extension explicitly even in pure DOS/Windows
environments to avoid that confusion and headache.

> My objective was always to make the scripts equally natural to use
> within each environment.  Under *nix environments, a shell
> association is given by a #! Directive - very clever and elegant
> but not part of Windows shells.

I consider that a DOS/Windows failing... DOS did a lot of things
against already established conventions, such as using a backslash
instead of a forward slash as the directory separator, just "to be
different".  As I understand it (I may be wrong), this is one of them.

> The key concern I have been addressing has been that CYGWIN's value
> is within the context of Windows - remove Windows and there is no
> reason for CYG"WIN" self-evidently.  For that reason, means to
> better integrate CYGWIN and Windows will inevitably benefit CYGWIN
> users.  Further, being a CYGWIN newbie, the initial disconnects
> between bash and CMD support for PATHEXT and the CR/LF issues in
> BASH as the first impediments faced by many users (lots of web
> hits) - if nothing else, perhaps explicit documentation of ways to
> mitigate these issues would help (Thanks again Bill Smith).
>
> Three isolated *nix-like environments have died under Windows -
> Interix, POSIX subsystem under NT, and I expect Ubuntu under Win10
> because of the lack of integration with Win32.  You can only do so
> much playing within a sandbox.  The only successful commercial
> product integrating Unix tools within Windows has been MKS and they
> do a great job of co-existing with and exploiting Win32 - that is
> why they are embedded and distributed with dozens of *nix products
> ported to Windows.  Why would such product vendors be willing to
> pay big bucks for MKS if CYGWIN is essentially free?  Perhaps, the
> degree of integration with Win32 is part of the  answer.  More
> corporate support for CYGWIN might increase financial support for
> CYGWIN developers and infrastructure.

There is a paid/commercial version of CYGWIN with Red Hat's backing.
This has been around for quite some time, and I know of several
corporations who have paid for it and deployed it.  People use tools
based on how well the tool fits their needs.  I personally don't
recall having encountered MKS myself, and doubt I would choose to use
it unless an employer was specifically hiring me to work with it.

> Doug Henderson:  Thank you for your thoughtfully laid out comments
> and argument.  Having supported mixed Solaris/Windows-MKS
> environments, I agree that PATHEXT is not necessarily great but it
> is part of Windows in the mind of any Windows programmer or admin
> which is sufficient justification for recognition within CYGWIN
> shells.

I disagree that Windows introducing something inconsistent and
sometimes unpredictable is a good reason to add it to other packages;
I would much sooner educate people on why it was a bad idea, and
poorly implemented, in the first place.

> *nix has #! - Windows shells have PATHEXT and registry file-
> associations.

These are two separate things, best not to conflate them.

> TAB completion only caters to interactive shells - it does not
> address the issue of scripts being run in both *nix and Win
> environments.

This is true.

> ... ... ... not including a suffix when invoking from scripts, two
> problems arise:  one - ported scripts would then have to support
> .sh or variants thereof in *nix or use something like  ${BAT} or
> ${CMD} as noted by Bill Smith - (Thanks again Bill)

This is what I do, I usually use ${suffix} and set at the start of
the script based on the detected environment.  In some cases, there
are multiple, depending on which suffix I need in Windows to avoid
foo.bat/foo.cmd/foo.exe/etc headaches.  Supporting Windows from *nix
systems definitely can be a headache.

> and  two, if referring to a third party pkg component, one then
> wires into a script an expectation that a given function will
> continue to be a CMD or BAT or EXE or whatever whereas that 3rd
> party package may be independently updated someday to implement
> that function in a different manner (e.g. CMD to EXE for speed)
> forcing you to re-release.

When depending on third party pieces, this is always a risk, and not
just for the extension.  For example, CLI options being changed in a
future version will also cause you to have to rerelease, and having
to support multiple different versions forces you to detect which
version happens to be available before using it.  Not ideal by any
means, but a part of the coder's life.

> Bash/sh/ksh/perl are so much better than CMD (why else am I trying
> to use CYGWIN?) that bash recognising PATHEXT would facilitate the
> transition (esp since there was a patch posted by somebody years
> ago which seemed to pass a cursory evaluation).

One of the problems I see with the idea in general is that it would
add a CYGWIN specific different behavior to the shell that would
exist no where else, and anyone who came to depend on it would see
their scripts fail badly and without explanation when trying to port
the same script to any *nix host.  One of the goals of cygwin is to
be as close to a direct Linux-like environment as possible, and so
there are very very few Windows-specific additions.  The only one
coming to my mind at the moment is the -W (captial W) option added to
ps to display the Windows processes in addition to the CYGWIN
processes.

> After 41 years of working with Unix (starting with release 6 on 2
> mag tapes from Bell Labs on a PDP 11/45 with 256KB)

I'm a little envious of this... I started Unix with a mag tape load,
but when I started that was already "this is the legacy, you may
never need this but better to know and not need than need and not
know."


> it still amazes me that Unix has not swept Windows away.  Religious
> fervour, intolerance, and the variety of sects ... have not helped.

Throughout human history, religious fervor and intolerance have been
the source of massive amounts of human stupidity.  Let us be thankful
that in computing, it has not resulted in things far far worse than
Windows.

-- Erik

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