# PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

60 messages
123
Open this post in threaded view
|

## PATHEXT is fundamental to Windows and Should be recognised by CYGWIN

 The CYGWIN site makes it quite difficult to discern how somebody can report an issue or comment. In any event, I subscribed to the cygwin mailing list and am replying to one of the many links sent to me in case this happens to be a way to comment. 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.  Without using extensions, bash can use execution privileges to determine if a file is executable.  However, that does not work when invoking a command from CMD.  This means that when invoked from BASH, you name a command "ZOT" but "ZOT.sh" (or similar) if invoked from CMD.  The published solutions in the various FAQs are not satisfactory. Creating links between ZOT.sh and ZOT creates substantial overhead.  If CYGWIN really intends to support Windows it should support its fundamental execution framework.  It should be equally easy to invoke a bash script from a bash script or a CMD script.  (This is not insurmountable as the MKS toolkit has supported this for decades.) Problem 2:  Cygwin does not support CR-LF delimiters.  For the same reason, it is unfortunate that CYGWIN/bash does not cope with both types of line delimiters transparently. I have been using and developing system software within Unix since 1974 and Windows since the mid-80's.  in more recent years (since the mid-90's) I have developed extensive sets of tools (sh/awk/etc..) for corporate and public sector clients - on the order of 100,000 lines of code for representative projects.  Most had to run under both Solaris and Windows environments for which I used the MKS toolkit. Michel LaBarre -- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

 On 03.08.2016 18:43, Michel LaBarre wrote: > Problem 1:  Cygwin does not support PATHEXT and really should. A casual websearch shows that this topic has come up before. For instance, someone posted, some decade ago, to the Cygwin mailing list, a patch against GNU Bash to make its command search algorithm take PATHEXT into account. > 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. I can't find any reference anywhere to PATHEXT being used outside of the CMD.EXE interpreter, which rather tends to make it substantially less than fundamental to Windows, though noteworthy. Certainly, CreateProcess does not use PATHEXT. I can't find any documentation which says that ShellExecuteEx uses PATHEXT, either. (Can anyone confirm?) Everything points to it being a CMD.EXE "gizmo". If you want to execute a command such that PATHEXT is taken into account, you have to spawn CMD.EXE /C . Cygwin provides a POSIX environment on Windows. Users of a POSIX environment don't expect a command "foo" to resolve to a file "foo.bat". If they want to run "foo.bat" they use "foo.bat". >  Without using extensions, bash can use execution privileges to > determine if > a file is executable.  However, that does not work when invoking a > command > from CMD. What does not work from CMD is Microsoft's problem, not Cygwin's. Yes, even though you have a "myscript.sh" and you do "chmod a+x myscript.sh" inside Cygwin, the outside Windows world doesn't agree that myscript.sh is now executable, and that it uses /bin/sh by default as its interpreter, if a #! line is absent, otherwise the interpreter nominated by the #! line. Adding ".sh" to PATHEXT might work in causing CMD.EXE to resolve "myscript" to "myscript.sh"; however, it will not then successfully execute "myscript.sh",  because the underlying CreateProcess API will not find it executable. CMD.EXE will probably *try* to execute it, and fail. > This means that when invoked from BASH, you name a command "ZOT" > but "ZOT.sh" (or similar) if invoked from CMD.  From CMD, you have do something explicit like this:    C:\Cygwin\bin\bash C:\Path\to\zot.sh That is, you have to run Bash, and pass it the script as an argument. Windows and CMD.EXE will not associate .sh with Bash and certainly won't look at any #! line you may have in the script. Not supporting arbitrary interpreters for scripts is a Windows problem/limitation. Cygwin overcomes that limitation within its "garden". If you solve the entry point problem of how to invoke Cygwin code from the outside, once you are in Cygwin land, you have no further problems. Scripts marked executable and containing #! use their respective interpreters and so on. > The published solutions in > the various FAQs are not satisfactory. Creating links between ZOT.sh > and ZOT > creates substantial overhead.   I don't think that will work, unless by "creating a link" you mean that you create a ZOT.BAT file shim which invokes the neighboring ZOT.sh by passing its full path to bash.exe. > If CYGWIN really intends to support Windows > it should support its fundamental execution framework.  It should be > equally > easy to invoke a bash script from a bash script or a CMD script. What you need on Windows is a script-to-EXE application deployment tool, which takes your "script.sh" and combines it with a copy of a special binary executable, and writes out the combination to "script.exe". Then even a raw CreateProcess Win32 API call can invoke "script.exe". > Problem 2:  Cygwin does not support CR-LF delimiters.  For the same > reason, > it is unfortunate that CYGWIN/bash does not cope with both types of > line > delimiters transparently. The way Cygwin deals with CR/LF has evolved over time, and there are various ways to deal with this, depending on the specific situation. Firstly, the binary mode default treatment for files comes from the mount table:    $mount C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) C:/Cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) See how that /cygdrive/c is mounted "binary" (as is everything else?) That's what causes text files to be treated as LF rather than CR/LF. That can be altered; you can mount some Windows path into Cygwin's POSIX file system view as text, and then CR/LF conversion is done. Then, secondly, there are approaches for individual C programs. If you're porting something written in C, the C library in Cygwin supports the "t" flag in fopen and related functions. This is similar to the Microsoft extension, found in the Visual C run-time library. In ISO C, if you omit the "b" mode, then a file is open in text mode, but on POSIX that is the same as binary mode. In Cygwin, if you specify "t", you get the Windows text mode, CR/LF. Without "t" or "b", I think it defaults to the mode from the mount table. So if you're working on porting a C program, that's one tool in your arsenal. As an alternative to introducing "t" into C programs, there is a link-time method. Cygwin provides several special .o object files that can be specified when linking a C program, which change its treatment of files in this regard. Note that some standard utilities for processing text, though written in C, do not use the C stdio library. So they don't respond to these mechanisms. For instance GNU Awk does its own I/O, and that is LF terminated. -- Problem reports: http://cygwin.com/problems.htmlFAQ: http://cygwin.com/faq/Documentation: http://cygwin.com/docs.htmlUnsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Reply | Threaded Open this post in threaded view | ## RE: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN  Thanks for the reply Kaz. I did not embed any comments in your reply for the sake of brevity. I had seen the reference to a patch to support PATHEXT; it was dismissed pretty lightly. PATHEXT has been part of Windows for as long as I can remember - back to the mid-80's - used by shells that run under windows (e.g. CMD, PowerShell, VBS, etc.). Windows inherently uses file suffixes to associate programs to data files, hence CMD files to CMD.exe, VBS to VB, etc.. All its shells refer to PATHEXT and/or file associations in the registry. I have worked with Unix for a long time (1974) and Windows for almost as long (1986?). Because some notion does not exist in Unix is no reason for discrediting it within Windows esp in the context of a tool framework specifically catering to Windows according to its defining mission. If you have been web-searching for references to my query, surely you have found many items referring to the problem in practice. I used to move a whack of scripts between Solaris and Windows - same scripts supporting an enterprise backup product with HQ hosted on Solaris and 150 sites worldwide running Windows only. My automated port process stripped or added suffixes as necessary going between Solaris and Windows. However, once in Windows, a tool could be called from a shell script or a CMD script without regard of the suffix - the (MKS) shell worked with the suffix or not while CMD (and vbs) relied upon PATHEXT. One has to look at practical applications when deciding what is warranted. I cannot help feeling that CYGWIN's proponents give lip service to interoperability with Windows - that they would rather be running Linux in a VM in which case why bother with a Windows foundation in the first place? Other than Microsoft fearing competition, the second biggest drawback to Windows developers adopting Unix tools has been due to Unix developers wishing that Windows would go away. MKS has done a great job of working with Windows. You may recall Interix which tried to launch a product that ran isolated within the POSIX subsystem - it went nowhere - Microsoft bought the dregs of the company for no rational reason I can discern. They released a Unix environment for NT and it tanked. They are trying again with Ubuntu under Windows 10 but that will fail as well because it will be completely isolated from the Win32 environment. Windows developers need to get to Windows tools and resources - CYGWIN could be a very smart supplement to that requirement. Windows 7 with the MKS Toolkit is in fact one of the most productive environments I have used. MKS's value lays in its integration with Windows. CYGWIN's developers recognising that Windows is not a passing fad might push CYGWIN into the mainstream of Windows development. As it stands, if getting into it is a challenge for people with plenty of Unix and Windows background, it will not make much headway with pure Windows programmers. Your comment regarding " What does not work from CMD is Microsoft's problem, not Cygwin's." ignores that Cygwin is supposed to work within Windows. You penalise CYGWIN users - not Microsoft. Frankly, that comment strikes me as somewhat cavalier. You commented: "Cygwin provides a POSIX environment on Windows. Users of a POSIX environment don't expect a command "foo" to resolve to a file "foo.bat". If they want to run "foo.bat" they use "foo.bat"." 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". And if you are in a script you expect to release to a large community, If "foo" comes from some 3rd party package released independently, then you don't want to be wiring into your script that "foo" is a bat, exe, vbs, cmd, or whatever in case the 3rd party package ever changes its implementation (e.g. converting a CMD to an EXE for performance reasons). I agree fully that PATHEXT is not a great mechanism - it just happens to be wired into Windows. It is a myth that Unix-y programmers work in a vacuum within Windows. Any serious software will have to exploit, hence interact with, Windows native and add-on tools. As for CR/LF, I admit that I have not mastered all the opportunities fstab might present under CYGWIN but I don't think they will apply if the bash script is invoked from a Windows environment rather than from a bash script would they. Thanks for your thoughts Kaz. I realise you are a volunteer and appreciate your efforts. Having cut my teeth on Unix, I appreciate its value however having been forced to work with Windows for so many decades, I have come to appreciate a few aspects. I just miss all the tools for day-to-day use I took for granted under Unix. 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. Cheers, Michel -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Kaz Kylheku Sent: August-03-16 10:55 PM To: Michel LaBarre Cc: [hidden email] Subject: Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN On 03.08.2016 18:43, Michel LaBarre wrote: > Problem 1: Cygwin does not support PATHEXT and really should. A casual websearch shows that this topic has come up before. For instance, someone posted, some decade ago, to the Cygwin mailing list, a patch against GNU Bash to make its command search algorithm take PATHEXT into account. > 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. I can't find any reference anywhere to PATHEXT being used outside of the CMD.EXE interpreter, which rather tends to make it substantially less than fundamental to Windows, though noteworthy. Certainly, CreateProcess does not use PATHEXT. I can't find any documentation which says that ShellExecuteEx uses PATHEXT, either. (Can anyone confirm?) Everything points to it being a CMD.EXE "gizmo". If you want to execute a command such that PATHEXT is taken into account, you have to spawn CMD.EXE /C . Cygwin provides a POSIX environment on Windows. Users of a POSIX environment don't expect a command "foo" to resolve to a file "foo.bat". If they want to run "foo.bat" they use "foo.bat". > Without using extensions, bash can use execution privileges to > determine if a file is executable. However, that does not work when > invoking a command from CMD. What does not work from CMD is Microsoft's problem, not Cygwin's. Yes, even though you have a "myscript.sh" and you do "chmod a+x myscript.sh" inside Cygwin, the outside Windows world doesn't agree that myscript.sh is now executable, and that it uses /bin/sh by default as its interpreter, if a #! line is absent, otherwise the interpreter nominated by the #! line. Adding ".sh" to PATHEXT might work in causing CMD.EXE to resolve "myscript" to "myscript.sh"; however, it will not then successfully execute "myscript.sh", because the underlying CreateProcess API will not find it executable. CMD.EXE will probably *try* to execute it, and fail. > This means that when invoked from BASH, you name a command "ZOT" > but "ZOT.sh" (or similar) if invoked from CMD. From CMD, you have do something explicit like this: C:\Cygwin\bin\bash C:\Path\to\zot.sh That is, you have to run Bash, and pass it the script as an argument. Windows and CMD.EXE will not associate .sh with Bash and certainly won't look at any #! line you may have in the script. Not supporting arbitrary interpreters for scripts is a Windows problem/limitation. Cygwin overcomes that limitation within its "garden". If you solve the entry point problem of how to invoke Cygwin code from the outside, once you are in Cygwin land, you have no further problems. Scripts marked executable and containing #! use their respective interpreters and so on. > The published solutions in > the various FAQs are not satisfactory. Creating links between ZOT.sh > and ZOT creates substantial overhead. I don't think that will work, unless by "creating a link" you mean that you create a ZOT.BAT file shim which invokes the neighboring ZOT.sh by passing its full path to bash.exe. > If CYGWIN really intends to support Windows it should support its > fundamental execution framework. It should be equally easy to invoke > a bash script from a bash script or a CMD script. What you need on Windows is a script-to-EXE application deployment tool, which takes your "script.sh" and combines it with a copy of a special binary executable, and writes out the combination to "script.exe". Then even a raw CreateProcess Win32 API call can invoke "script.exe". > Problem 2: Cygwin does not support CR-LF delimiters. For the same > reason, it is unfortunate that CYGWIN/bash does not cope with both > types of line delimiters transparently. The way Cygwin deals with CR/LF has evolved over time, and there are various ways to deal with this, depending on the specific situation. Firstly, the binary mode default treatment for files comes from the mount table:$ mount    C:/Cygwin/bin on /usr/bin type ntfs (binary,auto)    C:/Cygwin/lib on /usr/lib type ntfs (binary,auto)    C:/Cygwin on / type ntfs (binary,auto)    C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) See how that /cygdrive/c is mounted "binary" (as is everything else?) That's what causes text files to be treated as LF rather than CR/LF. That can be altered; you can mount some Windows path into Cygwin's POSIX file system view as text, and then CR/LF conversion is done. Then, secondly, there are approaches for individual C programs. If you're porting something written in C, the C library in Cygwin supports the "t" flag in fopen and related functions. This is similar to the Microsoft extension, found in the Visual C run-time library. In ISO C, if you omit the "b" mode, then a file is open in text mode, but on POSIX that is the same as binary mode. In Cygwin, if you specify "t", you get the Windows text mode, CR/LF. Without "t" or "b", I think it defaults to the mode from the mount table. So if you're working on porting a C program, that's one tool in your arsenal. As an alternative to introducing "t" into C programs, there is a link-time method. Cygwin provides several special .o object files that can be specified when linking a C program, which change its treatment of files in this regard. Note that some standard utilities for processing text, though written in C, do not use the C stdio library. So they don't respond to these mechanisms. For instance GNU Awk does its own I/O, and that is LF terminated. -- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple-- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 In reply to this post by Michel LaBarre > 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.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

Open this post in threaded view
|

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

 In reply to this post by Michel LaBarre Hi Michel, On Thu, Aug 4, 2016 at 6:30 AM, Michel LaBarre  wrote: > Thanks for the reply Kaz.  I did not embed any comments in your reply for the sake of brevity. Please don't top-post. For the sake of brevity:  https://cygwin.com/acronyms/#TOFUCsaba -- GCS a+ e++ d- C++ ULS$L+$ !E- W++ P+++$w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 In reply to this post by Michel LaBarre Greetings, Michel LaBarre! > Problem 1:  Cygwin does not support PATHEXT and really should. No, it should not. Cygwin is a POSIX environment, and it uses POSIX conventions to determine if a file is executable somehow. > PATHEXT is as fundamental component of Windows program execution as PATH. PATHEXT is a shell (CMD) extension. Some programs do make use of it, notable file managers and CMD replacements do, but overall, this is a mechanism of finding the file to execute, not of executing it per se. You can write your own extension to bash-completion "file-not-found" handler, if you so desire. > Problem 2:  Cygwin does not support CR-LF delimiters. Cygwin, in this case, is a library (newlib), and it doesn't care about delimiters. This is an application's choice and right to support various EOL's or not. > For the same reason, it is unfortunate that CYGWIN/bash does not cope bash do cope, if you tell it to do. So does Cygwin, if you use text mounts. Which is a sure way to destroy your data and cause lots of other messy behavior. > with both types of line delimiters transparently. -transparently +ambiguously > I have been using and developing system software within Unix since 1974 and > Windows since the mid-80's.  in more recent years (since the mid-90's) I > have developed extensive sets of tools (sh/awk/etc..) for corporate and > public sector clients - on the order of 100,000 lines of code for > representative projects.  Most had to run under both Solaris and Windows > environments for which I used the MKS toolkit. And they do run fine, as long as you are not making stupid mistakes, like using bogus EOL terminators and expecting the program to work equally on different systems. -- With best regards, Andrey Repin Thursday, August 4, 2016 15:03:06 Sorry for my terrible english...
Open this post in threaded view
|

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

 In reply to this post by Kaz Kylheku-5 Greetings, Kaz Kylheku! > I can't find any reference anywhere to PATHEXT being used outside > of the CMD.EXE interpreter, which rather tends to make it substantially > less than fundamental to Windows, though noteworthy. > Certainly, CreateProcess does not use PATHEXT. > I can't find any documentation which says that ShellExecuteEx > uses PATHEXT, either. (Can anyone confirm?) ShellExecute(Ex) uses its own discovery mechanism with hardcoded order. PATHEXT is meaningless for this case. It's a CMD's (and some other shells and file managers) setting to find executable object in a specified order. Not a mechanic to determine, how to execute it. >>  Without using extensions, bash can use execution privileges to >> determine if >> a file is executable.  However, that does not work when invoking a >> command >> from CMD. > What does not work from CMD is Microsoft's problem, not Cygwin's. > Yes, even though you have a "myscript.sh" and you do "chmod a+x > myscript.sh" > inside Cygwin, the outside Windows world doesn't agree that myscript.sh > is now executable, and that it uses /bin/sh by default as its > interpreter, > if a #! line is absent, otherwise the interpreter nominated by the #! > line. > Adding ".sh" to PATHEXT might work in causing CMD.EXE to resolve > "myscript" to "myscript.sh"; however, it will not then successfully > execute "myscript.sh",  because the underlying CreateProcess API > will not find it executable. > CMD.EXE will probably *try* to execute it, and fail. Not, if you provide a file association. :) [C:\Users\anrdaemon\Documents\_pas\ShExETest]$echo %PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1;.MSC;.BTM;.PHP;.SH [C:\Users\anrdaemon\Documents\_pas\ShExETest]$ assoc .sh .sh=unixshell.script [C:\Users\anrdaemon\Documents\_pas\ShExETest]$ftype unixshell.script unixshell.script="C:\Programs\Cygwin_64\bin\cygwrap.cmd" "%1" %* > Not supporting arbitrary interpreters for scripts is a Windows > problem/limitation. To be fair, CMD have this mechanics, but it's compatible with shebang in the least. To begin with, it uses an explicit command your interpreter has to know and discard, rather than a widely-accepted as a comment the '#' char. > What you need on Windows is a script-to-EXE application deployment tool, > which takes your "script.sh" and combines it with a copy of a special > binary executable, and writes out the combination to "script.exe". > Then even a raw CreateProcess Win32 API call can invoke "script.exe". You're overcomplicating it. > Firstly, the binary mode default treatment for files comes > from the mount table: >$ mount >    C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) >    C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) >    C:/Cygwin on / type ntfs (binary,auto) >    C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > See how that /cygdrive/c is mounted "binary" (as is everything else?) > That's what causes text files to be treated as LF rather than CR/LF. > That can be altered; you can mount some Windows path into Cygwin's > POSIX file system view as text, and then CR/LF conversion is done. And in turn cause short reads, size miscalculations and overall corruption of the data. "text" mounts and modes were discouraged for ages, if not decades, by now. -- With best regards, Andrey Repin Thursday, August 4, 2016 15:13:11 Sorry for my terrible english...
Open this post in threaded view
|

 In reply to this post by Andrey Repin > > Problem 1:  Cygwin does not support PATHEXT and really should. > > No, it should not. Cygwin is a POSIX environment, and it uses POSIX > conventions to determine if a file is executable somehow. > > > PATHEXT is as fundamental component of Windows program execution as > PATH. > > PATHEXT is a shell (CMD) extension. Some programs do make use of it, > notable file managers and CMD replacements do, but overall, this is a > mechanism of finding the file to execute, not of executing it per se. > You can write your own extension to bash-completion "file-not-found" > handler, if you so desire. [Bill Smith] A couple of years ago I was involved with porting a very large code base of makefiles & shell scripts to work with Cygwin.  In our environment, the main issue was shell scripts calling *.bat files without the .bat suffix because of the $PATHEXT. The fix was to change somescript To somescript${BAT} where ${BAT} would be set to .bat on Windows. Another option available was to create wrapper shell script. So I would create a script named "somescript" that is only in$PATH on Windows and it would look something like this: #!/bin/sh adaptman.bat "$@" Granted our *.bat files are simple and don't have to worry about arguments with spaces. > > Problem 2: Cygwin does not support CR-LF delimiters. > > Cygwin, in this case, is a library (newlib), and it doesn't care about delimiters. > This is an application's choice and right to support various EOL's or not. > > > For the same reason, it is unfortunate that CYGWIN/bash does not cope [Bill Smith] You can tell bash to ignore carriage returns in scripts by doing the following: set -o igncr export SHELLOPTS > > I have been using and developing system software within Unix since > > 1974 and Windows since the mid-80's. in more recent years (since the > > mid-90's) I have developed extensive sets of tools (sh/awk/etc..) for > > corporate and public sector clients - on the order of 100,000 lines of > > code for representative projects. Most had to run under both Solaris > > and Windows environments for which I used the MKS toolkit. > > And they do run fine, as long as you are not making stupid mistakes, like > using bogus EOL terminators and expecting the program to work equally on > different systems. [Bill Smith] Agreed. If you need advice on porting scripts to work both in Cygwin and MKS, feel free to send me email. -- Problem reports: http://cygwin.com/problems.htmlFAQ: http://cygwin.com/faq/Documentation: http://cygwin.com/docs.htmlUnsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Reply | Threaded Open this post in threaded view | ## Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN  In reply to this post by Michel LaBarre Greetings, Michel LaBarre! > I had seen the reference to a patch to support PATHEXT; it was dismissed > pretty lightly. > PATHEXT has been part of Windows Part of CMD.exe. Not Windows. > for as long as I can remember - back to the mid-80's - used by shells that > run under windows (e.g. CMD, PowerShell, VBS, etc.). Shells =/= Operating system. > Windows inherently uses file suffixes to associate programs to > data files, hence CMD files to CMD.exe, VBS to VB, etc.. Right. And wrong at the same time. There's a hardcoded behavior of CreateProcess to execute .BAT and .CMD files with cmd.exe. Even ignoring %ComSpec%, as I recall, in case it was compromised. ShellExecute(Ex), of course, doesn't do that, as it uses associations to find ways to execute the object. Yet again, this has no relation to PATHEXT. As demonstrated by Kaz earlier, just adding an extension to search order will not make a script executable by the shell. > All its shells refer to PATHEXT and/or file associations in the registry. Do NOT mix PATHEXT and file associations, they are NOT the same thing. PATHEXT is a discovery mechanics, shell associations is an execution mechanics. > I have worked with Unix for a long time (1974) and Windows for almost as > long (1986?). Then you should know better than to present easily disprovable arguments. > Because some notion does not exist in Unix is no reason for > discrediting it within Windows esp in the context of a tool framework > specifically catering to Windows according to its defining mission. If you > have been web-searching for references to my query, surely you have found > many items referring to the problem in practice. > I used to move a whack of scripts between Solaris and Windows - same scripts > supporting an enterprise backup product with HQ hosted on Solaris and 150 > sites worldwide running Windows only. My automated port process stripped or > added suffixes as necessary going between Solaris and Windows. However, > once in Windows, a tool could be called from a shell script or a CMD script > without regard of the suffix - the (MKS) shell worked with the suffix or not > while CMD (and vbs) relied upon PATHEXT. Then you just made your life hard for yourself. If you would NOT change suffixes, but have added them from the start, knowing that your toolset may be run on Windows, you would have never encountered such issues. > One has to look at practical applications when deciding what is warranted. > I cannot help feeling that CYGWIN's proponents give lip service to > interoperability with Windows - that they would rather be running Linux in a > VM in which case why bother with a Windows foundation in the first place? > Other than Microsoft fearing competition, the second biggest drawback to > Windows developers adopting Unix tools has been due to Unix developers > wishing that Windows would go away. Do you want to know, why Windows developers adopt *NIX tools? I'll tel you why - because they interoperate in a standardized and predictable way. With any other tools. You can pipe an output of a Cygwin grep to a CMD's FOR statement and it'll consume and process it without a hitch. On the other hand, Windows tools in 99.(9)% of cases are burdensome bunch, spewing tons of crap and impossible to manage. > MKS's value lays in its integration with Windows. CYGWIN's developers > recognising that Windows is not a passing fad might push CYGWIN into the > mainstream of Windows development. But it is not approved by Microsoft!! (You have no idea, how many times people say that, and this is the main reason the evolution happens outside Windows world.) > As it stands, if getting into it is a challenge for people with plenty of > Unix and Windows background, it will not make much headway with pure > Windows programmers. "Pure Windows programmers" are hell bent on Microsoft tools and see everything else as a heresy. > Your comment regarding "What does not work from CMD is Microsoft's > problem, not Cygwin's." ignores that Cygwin is supposed to work within > Windows. And it does work. For me, the biggest problem with working with Cygwin apps from native shells is impossibility to tell CMD to shut the fuck up when I Ctrl+C the Cygwin script. Always pops with "do you want to terminate batch file yes no" idiocy. Got so tired that I've moved my wrappers to TCC. "ON BREAK REM" and no problem. > You penalise CYGWIN users - not Microsoft. Frankly, that comment > strikes me as somewhat cavalier. How the hell you've drawn such a conclusion? If you have no idea how CMD works, or how to make it behave, ask me. Off list. This is not a Cygwin question. > You commented: > "Cygwin provides a POSIX environment on Windows. Users of a POSIX > environment don't expect a command "foo" to resolve to a file "foo.bat". If > they want to run "foo.bat" they use "foo.bat"." > I disagree completely. *You* disagree is the right wording. But we have an equal right to disagree, too. > 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. Period. If I want to run foo.bat, I will type "foo.bat". Because otherwise it may execute any random crap without my full consent. > And if you are in a script you expect to release to a large community, If > "foo" comes from some 3rd party package released independently, then you > don't want to be wiring into your script that "foo" is a bat, exe, vbs, cmd, > or whatever in case the 3rd party package ever changes its implementation > (e.g. converting a CMD to an EXE for performance reasons). > I agree fully that PATHEXT is not a great mechanism - it just happens to be > wired into Windows. Gosh. Try it yourself. Make a program calling "CreateProcess('test');" and let's see how it would execute your test.sh. Then talk about what is wired into Windows. (Hint: ShellExecute(Ex) is not a Windows (WinAPI) functionality, it is ShellAPI functionality. But even ShellExecute(Ex) does not refer to the PATHEXT.) > It is a myth that Unix-y programmers work in a vacuum within Windows. Nice discussion we have here. Making up statements to "disprove" them. > As for CR/LF, I admit that I have not mastered all the opportunities fstab > might present under CYGWIN but I don't think they will apply if the bash > script is invoked from a Windows environment rather than from a bash script would they. May be you should read documentation before making conclusions? Any Cygwin app initialize with cygwin1.dll, which, you may say, IS THE "Cygwin" in the essence. What lets an application a chance to be called a "Cygwin" application. (But not necessarily allows... but that's a different topic.) And fstab is managed in the Cygwin layer. As long as you are using POSIX calls, the Cygwin subsystem will provide the rest. P.S. The main obstacle to everyday Windows user like me is path translation. Not what you were writing in so many words here. Not an unavoidable obstacle, if you have a powerful [enough] shell tools, but still an impediment in some case. P.P.S. If you do not want to quote the original mail in your reply, take your time to remove it. And this list is "no top posting please, thank you". So, thank you in advance. -- With best regards, Andrey Repin Thursday, August 4, 2016 16:39:20 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.htmlFAQ: http://cygwin.com/faq/Documentation: http://cygwin.com/docs.htmlUnsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Reply | Threaded Open this post in threaded view | ## Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN  In reply to this post by Bill Smith Greetings, Bill Smith! > A couple of years ago I was involved with porting a very large code base of > makefiles & shell scripts to work with Cygwin. In our environment, the main > issue was shell scripts calling *.bat files without the .bat suffix because > of the$PATHEXT. Sounds like it wasn't a *NIX code base. > The fix was to change > somescript > To > somescript${BAT} > where${BAT} would be set to .bat on Windows. In this case, just changing the calls to use real names would've sufficed. > Another option available was to create wrapper shell script.  So I would create a script named "somescript" > that is only in $PATH on Windows and it would look something like this: > #!/bin/sh > adaptman.bat "$@" > Granted our *.bat files are simple and don't have to worry about arguments with spaces. No, this is a very messy way to do it. Highly prone to backfires. Correct way would've been (assuming this code base of yours is not purely Windows, like I thought) is to use same shell scripts it would call otherwise, instead of bat files, and enhance them to find relevant bits of information if run under Cygwin, where applicable. Then discard the .bat files and breathe free at last. -- With best regards, Andrey Repin Thursday, August 4, 2016 17:36:13 Sorry for my terrible english... -- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 In reply to this post by Vince Rice 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: [hidden email] [mailto:[hidden email]] 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.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple-- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 Michael, You need to configure your email client to wrap your text at no more than 78 characters, 72 would be even better.  It helps quoting what you write better. You also need to stop top posting or remove the trailing mail from the reply if quoting that particular mail isn't necessary. Cygwin Community, This conversation has driven me bonkers.  Cygwin is a tool for windows first and foremost.  It was designed to help make life for those who support both UNIX and Windows servers a little easier by not having to convert scripts and utilities.  Cygwin is now trying to be something more by becoming even more UNIX like.  Some of the changes that have occurred are presenting havoc on those of us who have used a mix of applications, some Cygwin runtime and some Windows runtime.  This makes it difficult as is evidenced by the complaints in this list about ACL issues. With the PATHEXT debate Michael (and others before him) is stating that it would be nice if Cygwin, like its competitors, could use the PATHEXT variable to determine if the file can be executed by extension.  The naysayers are stating that it isn't POSIX or UNIX behavior; I agree with that statement.  I don't agree that Cygwin cannot use this variable to determine if a file is executable.  Cygwin doesn't have to determine the program to use, the Windows API has the smarts for that.  All Cygwin needs to do is to pass the file path to the API to execute the file. Cygwin even now makes an exception for files ending in .exe; see the output of 'ls -l /bin/ls' versus 'ls -l /bin/ls*'. I've stated this to cast my support for using PATHEXT even if it is a filtered option via the CYGWIN variable.  Michael are you willing to provide code? -- cyg Simple -- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 In reply to this post by Michel LaBarre 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.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 In reply to this post by cyg Simple On 8/5/2016 10:12 AM, cyg Simple wrote: > Cygwin is a tool for windows > first and foremost.  It was designed to help make life for those who > support both UNIX and Windows servers a little easier by not having to > convert scripts and utilities. Well, that's one point of view.  Mine is that I get the standard tools of Windows, kind of expected by business colleagues, etc., such as MS Office and the like, while also getting my familiar (Unix) coding environment for my classes and research (I am a computer science professor).  I do maintain some personal scripts across platforms, but I do not see that as Cygwin's primary purpose.  I would put it this way, which I think is capture's Cygwin's stated goals: To provide a POSIX environment (as close as is practical) running natively under Windows (not within a separate virtual machine), allowing the vast majority of POSIX compatible programs to be built on and to run under Cygwin on Windows platforms. That said, I wouldn't necessarily mind if PATHEXT were supported as an optional extension, if it makes life easier for some folks.  If you're going to do that, I think you get a better result by building it into the cygwin.dll as opposed to making it a feature only of bash.  I can see some of the arguments against PATHEXT, which is why I think it would need to be an option. Regards -- Eliot Moss -- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 In reply to this post by cyg Simple Hello cygsimple, Thanks for the advice regarding line length. I will try to remember to rein in my margins when emailing to cygwin. Thanks for your recognition of PATHEXT's potential value; reassuring to know I am not alone in my delusions. Regarding providing code, I am somewhat stale (though I spent my first 20 work years immersed in system code, assembly/C/Algol/Pascal/C++, building firmware for bit-sliced processors, etc.) The patch to which I referred is one I found while researching the topic; https://cygwin.com/ml/cygwin/2007-09/msg00127.html is one reference to it. It is old and likely out of date. Michel (as opposed to Michael... ) -- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 On Aug  5 11:20, Michel LaBarre wrote: > Hello cygsimple, > > Thanks for the advice regarding line length. > I will try to remember to rein in my margins when emailing to cygwin. > > Thanks for your recognition of PATHEXT's potential value; > reassuring to know I am not alone in my delusions. > > Regarding providing code, I am somewhat stale (though I spent my first 20 work years > immersed in system code, assembly/C/Algol/Pascal/C++, building firmware for bit-sliced processors, etc.) > > The patch to which I referred is one I found while researching the topic; > https://cygwin.com/ml/cygwin/2007-09/msg00127.html is one reference to it. > It is old and likely out of date. That.  Plus, the refusal from cgf is still valid today.  If you see the code required to handle .exe and .lnk extensions you don't *want* PATHEXT support anymore. Corinna -- Corinna Vinschen                  Please, send mails regarding Cygwin to Cygwin Maintainer                 cygwin AT cygwin DOT com Red Hat signature.asc (836 bytes) Download Attachment
Open this post in threaded view
|

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

 In reply to this post by Michel LaBarre [private, off-list reply] Hi Michael, Do you have some sort of list of detailed requirements implemented by MKS tools where Cygwin is different or lacking in some way? Maybe Cygwin could pick up some of them. Anyway, about a month ago, when I learned that Cygwin is now under the Lesser GPL, I started a project called Cygnal (Cygwin Native Application Library) whose goal is to improve the usefulness of Cygwin for Windows development. http://www.kylheku.com/cygnalHowever, I have a different angle on it: the perspective is of developing a native application (which ships native executables, without any apparent POSIX environment with a shell, commands or any of that). I don't need to infuse the Cygwin environment with Windows conventions; building my program within the POSIX conventions suits me just fine. However, I don't want the *users* of the program (a binary .exe accompanied by .dll files, wrapped up in an installer) to be exposed to POSIX conventions. With Cygnal, you can develop a single executable file, which works with POSIX and Windows conventions, simply based on which flavor of the cygwin1.dll it is linking against. Cheers ... -- Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Open this post in threaded view
|

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

 In reply to this post by Erik Soderquist-2 From: Erik Soderquist > ... 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". Not just to be different, but to distinguish from slashes used as command qualifiers (a la VMS), don't you think? --Ken Nellis