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


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