This is the mail archive of the
mailing list for the Cygwin project.
Re: Extra CR symbol from backticks on Cygwin 2.9.0
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
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple