Well my first foray into the world of CYGWIN mailing lists has been a lot of
fun so far. Rather than replying to each respondent, I will try to respond to
each in one email. This may be a mistake. At least people who think I am an
idiot will only have one email to delete instead of one per respondent.
Vince Rice: thank you for replying despite the obvious frustration I seem to
have caused you.
Vince: my perceived difficulty "in reporting an issue or comment" has more to
do with my not wanting to SPAM an entire mailing list. My expectation was that
there might be a less pervasive mechanism to which I could display my
ignorance/confusion than the whole wide world of cygwin-interested parties.
The fact that any/every issue gets communicated to everybody may explain the
"annoyance" evident in some of the replies I have received. There will always
be newbies - maybe we need a less intrusive means to communicate through.
Vince: regarding your "to you" observations - I was merely quoting the first
item in the Cygwin faq. Perhaps there are ways to mitigate the issues I
raised. Notably, Bill Smith has very helpfully noted the "set -o igncr" for
which I am very grateful - thank you Bill. As for your experience with GYGWIN
Vince, perhaps you have never experienced a need for PATHEXT but 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. 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. 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.
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. *nix has #! - Windows shells have PATHEXT
and registry file-associations. Your message did note issues inherent to
integration with Windows not supporting #!. Unfortunately PATHEXT and file
association is the Windows way. TAB completion only caters to interactive
shells - it does not address the issue of scripts being run in both *nix and
Win environments. As for "being a fool" for 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) 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. (As noted below, my focus has been tool (compiled
code and script) invocations from scripts, not low level invocations from an
API.)
Bill Smith: Thanks again. I have already acknowledged your points wrt PATHEXT
and CR/LF. Regarding PATHEXT, you noted the use of wrapper scripts with the
caveat of issues if needing to handle complex parameters - that applies in
spades if you consider the syntax of parameters for sh/bash/ksh vs CMD (or
other wrappers) - there be dragons! You wind up with escape characters up the
wazoo to say nothing of subtle differences in handling I/O redirection, file
descriptors, and ENV inheritance.
Finally, Andrey Repin (if anybody has lasted through all this): Thank you for
your insights. I fully appreciate the difference between an O/S and a shell
though it is apparent that your depth of experience with low level interfaces
exceeds mine and is much more current. Regarding PATHEXT, it is used
consistently by enough shells within Windows that it is part of the background
by now. I admit that I am for the most part referring to scripts in various
shells and not tools invoked by low level programs using CreateProcess. I
should have limited my comments to bash rather than CYGWIN. Lots of people
build extensive tool sets never having to delve into low level code.
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).
Thanks to you all. We can likely let this topic rest for a while. In the
meantime, I will persevere. I can work with anything and for my current needs
I can cobble something that will work. All those CYGWIN users cannot be wrong
after all. ;-)
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), in various
hardware/software/consulting companies in Canada and the USA, it still amazes
me that Unix has not swept Windows away. Religious fervour, intolerance, and
the variety of sects (a marketing VP once asked me, "ok - if we were to support
Unix, which flavour?") have not helped. Today, easier co-existence with
Windows might help enlighten potential converts - I have amazed countless
Windows folks with KSH, AWK, and regexp brevity and elegance (let alone VI).
Powershell is great for C#/C++ programmers wanting a break but lethal to
admins/integrators/scripters.
Cheers,
Michel
-----Original Message-----
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
Vince Rice
Sent: August-04-16 1:40 AM
To: Cygwin Mailing List
Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by
CYGWIN
> On Aug 3, 2016, at 8:43 PM, Michel LaBarre wrote:
>
> The CYGWIN site makes it quite difficult to discern how somebody can
> report an issue or comment.
If you think a plainly labeled “Reporting Problems” and “Mailing Lists” in the
prominent sidebar is difficult, then I’m afraid it’s only going to get worse
from here.
> Problem 1: Cygwin does not support PATHEXT and really should.
>
> Fundamental reason: from the Cygwin FAQ - What is it? "Cygwin is a
> distribution of popular GNU and other Open Source tools running on
> Microsoft Windows.”
> PATHEXT is as fundamental component of Windows program execution as PATH.
“To you.” Almost every sentence in that paragraph should have “to you” at the
end. I’ve used Cygwin for over a dozen years, and I have never once missed
having PATHEXT in mintty/bash.
You can continue to use PATHEXT to your heart’s content in CMD.
Bash isn’t CMD.
> The published solutions in the various FAQs are not satisfactory.
“To you."
> Problem 2: Cygwin does not support CR-LF delimiters.
Yes it does, although it is heartily suggested they be left behind (pretty much
any Windows program can handle Unix line endings but Notepad, and anyone using
Notepad has bigger issues than line endings).
Text mounts can be created in Cygwin (although, again, not suggested). There
are also a few (non-standard) things in Cygwin’s bash to try to handle CRLF
scripts. You can search the archives for more information.
> CYGWIN could be a very smart supplement to that requirement.
> …
> If CYGWIN could mitigate some of the recurring impediments new users trip
> over, (as evidenced by the many web-references to both my problems) it would
> facilitate its adoption by both Unix and non-Unix types.
No, Cygwin _is_ a very smart supplement to that requirement. You talk as if
Cygwin just showed up last week. It’s been around for almost twenty years, is
widely used and widely respected.
> I disagree completely. If you are in an interactive bash, running on a
> Windows computer, you sure as hell expect to be able to run "foo.bat" by
> typing "foo”.
No, _you_ expect to. I don’t. I know that Bash isn’t CMD.
Cygwin is providing a Posix environment on Windows. If you want a Windows
environment on Windows, then use CMD. Almost all of Cygwin’s supplied programs
work perfectly well in CMD, as long as you remember they’re providing a Posix
environment and therefore need Unix paths, etc.
--
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
--
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
