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: 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
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


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