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: Bash 3.1.17(8) CR/LF problem


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Malcolm Nixon on 9/27/2006 4:09 PM:
> mwoehlke wrote:
>> Right; non-standard behavior (and any non-binary treatment
>> of '\r' certainly counts!) should - and I might dare even to say
>> "must" - be disabled by default. Although in this case I can't
>> think of any reason why you would ever have a '\r' in a shell
>> script (other than as part of a line ending). Although if we
>> make any of this optional, then IMO it needs to be done the
>> right way, which is to just ignore '\r', at least at the end of
>> lines. That way we can ALWAYS read in binary mode, and
>> it isn't a major performance penalty.
> 
> I guess I'm 50/50 here. On one hand <CR> is most certainly
> not a standard line terminator character on Unix systems, but
> at the same time Cygwin advertises a "collection of tools which
> provide Linux look and feel" for Windows.

Here's my take on it.  If you want POSIX behavior and Linux compatibility,
use binary mounts and LF line endings, and don't edit files with notepad.
 If you want Windows behavior, where text and binary are not synonymous,
but where \r is generally ignored when treating a file as text, and where
you can develop in notepad (ugh, the thought makes me cringe in horror :),
then use text mounts.  Binary vs. text mounts only affects how _cygwin_
programs will react to your data; the underlying data is untouched when
viewed by non-cygwin programs.

By the way, there is another option that has not been mentioned in this
thread yet:

Make the first lines of your script read as follows:

#!/bin/sh
IFS=' ''	''
' # Yes, that was a space, tab, and line ending
# On Linux and cygwin text mounts, the last component is just \n.
# On cygwin binary mounts, when the file has \r\n line endings,
# whether by accident or by perforce (pardon the pun),
# the last component is \r\n; now bash will silently ignore literal
# carriage returns, and your \r\n script will still work on a binary
# cygwin mount.  Case solved.

By setting IFS properly, you can solve your chicken-and-egg problem of
using a \r\n script on a binary mount to determine how to change the
environment for all subsequent scripts invoked in your build process.

> 
> If pure Linux compatibility/restrictions was the only goal, then
> it could be achieved far easier by running Debian in a VM.
> 
> Instead Cygwin tries to add the power of the Linux-like tools
> into the cruftiness of Windows. Unfortunately I believe that implies
> supporting Windows/DOS crufty CR/LF files.

I am only willing supporting the crufty CRLF transparently _when it does
not penalize people who could care less about using notepad_.  In other
words, I try hard to make sure that my packages work sanely with CRLF
files on text mounts, but I have no sympathy for breakages that occur due
to improper CRLF endings on binary mounts.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
volunteer cygwin bash maintainer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFGyHt84KuGfSFAYARAkkKAJ9V+zAjyAuzUIxJN33LCxIehoXeygCfTGor
3yPOy7kSjHQ3RTDTdMsuvSg=
=lHA0
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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