This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN


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-owner@cygwin.com [mailto:cygwin-owner@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]