On 2017-09-13 08:34, cyg Simple wrote: > On 9/12/2017 8:11 PM, Michel LaBarre wrote: >> Not trying to sound like a jerk, but I am still not clear as to why CYGWIN >> users are not using Linux unless they have to support code running in both >> POSIX and Windows environments in which case, the CYGWIN mission could be >> elaborated to mention facilitating portability to, and integration with, >> Windows which go beyond just standards compliance. This might elevate >> deviations, such as "igncr", from being perceived as catering to the lazy, >> non-purist, unwashed masses rather than as genuinely valuable and essential >> elements of CYGWIN. > Because there are vendors who supply applications that our employers > purchase and tell us to support it. Those applications could be on > Linux or on Windows or whatever OS. Having the same scripts to support > many various operations be exactly the same for each operation is > helpful from a maintenance POV. If it works on Cygwin I can know that > it will work on Linux. If it works on Linux it may or may not work in > Cygwin just because of the extra CR Windows is famous for. If it works > on Linux it may or may not work on some other *nix OS but if that *nix > is POSIX compliant most likely it will especially if extensions weren't > used in the scripts. >> Strict POSIX compliance suits developers of self-contained vertical >> applications with minimal need for deviations; the whole application is >> safely ensconced within a POSIX cocoon. On the other hand, developers >> integrating Windows applications and services over which they have no >> control may need more flexibility. > Most have issues when they try to use Cygwin outside of the Cygwin > shell. While Cygwin tries to be helpful with that method it isn't the > suggested method of use and has lack of testers for changes. If you use > Cygwin outside of the Cygwin "ensconced POSIX cocoon" then when a test > version of Cygwin is released and a call for testers then you'd be > better served by testing and reporting issues than being surprised when > updating after it is released. >> That being said, it has been generous on the part of CYGWIN implementors >> to recognise the CYGWIN audience for whom strict POSIX compliance is >> secondary and the main objective is to have useful tools under Windows that >> also support portability outside Windows. Thank you. > Cygwin has never been totally empathetic to Windows executables. There > are many things that work but for each one that works there is another > that won't. You can't expect that a Windows executable to understand > the POSIX PATH emulation for instance. If you try to mix and match > executables between Cygwin and Windows you may have luck with a > particular version but later find that it no longer works because some > small change now causes you issues. Live inside the Cygwin environment > as much as possible and limit the amount of pure Windows applications > you use. I know there are many times when it's preferable to use a > Windows version versus a Cygwin version of an application gvIm is one I > use as a Windows app but I create a script to manage the PATH given to > the gvim.exe application. When playing with Windows applications you > have to be willing to work around the differences, it is usually > possible and if you have issues with trying to do so then this list is > here to help.
+1 for Windows native gvim with wrappers, and other Windows native GUIs like BitKeeper, Tortoise git and Hg, Firefox, Thunderbird, Libre/OpenOffice, etc. many of which can be invoked on files with cygstart due to auto-path-conversion. I have also found Windows Subsystem for Linux/Bash for Windows useful mainly for quick, convenient compatibility cross checks of scripts, source programs, and packages. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
