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