Eric Blake wrote:
#!/bin/sh
IFS=' ''''
' # Yes, that was a space, tab, and line ending
I retract this suggestion. On further investigation, bash currently does
not treat \r as an IFS whitespace character, and the hacks to the source
to make this happen are too invasive for my liking.
Malcolm Nixon wrote:
* Some translate files to a Local format (CR/LF on Windows).
FCOL, what on earth does an rcs think it's playing at, tampering with
your
data? Any rcs that doesn't give you back exactly what you put into it
is just
plain buggy. Nobody asked for a automatically mangle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 9/27/2006 7:14 PM:
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,
Malcolm Nixon wrote:
I recently updated to Bash 3.1.17(8) and found my local build system
failing due to the removal of CR/LF support:
A script on a binary mount that uses \r\n line endings will probably
encounter syntax errors or odd variable assignments, because the \r is
treated literally.
Malcolm Nixon wrote:
Unfortunately simply running d2u isn't a solution because:
* Some revision control systems make the files read-only.
I would venture to guess that *all* sccs make a file read-only.
* Some detect the change to LF as changes require manual merging.
It ought to, if
So why isn't using a textmode mount a solution?
Packages generally contain the sources, build scripts, tools binaries, etc
in a single directory tree. For example a ./configure script located in the
package root directory along side other project files. As such placing just
the bash scripts in a
Jonathan Arnold wrote:
* Some translate files to a Local format (CR/LF on Windows).
Perforce will do this if you let it. Or you can set the LineEnd option
for the client to be Unix or Share.
This was in fact my original patch attempt, however it had the following
problems:
* You can
Malcolm Nixon wrote:
I recently updated to Bash 3.1.17(8) and found my local build system
failing due to the removal of CR/LF support:
A script on a binary mount that uses \r\n line endings will probably
encounter syntax errors or odd variable assignments, because the \r is
treated literally.
Jonathan Arnold wrote:
Malcolm Nixon wrote:
Unfortunately simply running d2u isn't a solution because:
* Some revision control systems make the files read-only.
I would venture to guess that *all* sccs make a file read-only.
I know svn doesn't... rcs's that have a concept of edit usually
Dave Korn wrote:
On 27 September 2006 20:42, Malcolm Nixon wrote:
In my opinion a better solution would have been to err on the side of
compatibility and only use the new fast readline code if manually
enabled.
Then according to your opinion, everyone else in the world has to suffer
from
Malcolm Nixon wrote:
So why isn't using a textmode mount a solution?
Packages generally contain the sources, build scripts, tools binaries, etc
in a single directory tree. For example a ./configure script located in the
package root directory along side other project files. As such placing just
On 09/27/2006, Malcolm Nixon wrote:
So why isn't using a textmode mount a solution?
Packages generally contain the sources, build scripts, tools binaries, etc
in a single directory tree. For example a ./configure script located in the
package root directory along side other project files. As
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
On Wed, 27 Sep 2006, Malcolm Nixon wrote:
So why isn't using a textmode mount a solution?
Packages generally contain the sources, build scripts, tools binaries,
etc in a single directory tree. For example a ./configure script located
in the package root directory along side other project
Malcolm Nixon wrote:
Jonathan Arnold wrote:
* Some translate files to a Local format (CR/LF on Windows).
Perforce will do this if you let it. Or you can set the LineEnd option
for the client to be Unix or Share.
This was in fact my original patch attempt, however it had the following
Malcolm Nixon wrote:
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
Jonathan Arnold wrote:
You can change the Perforce filetype to be binary, and that way Perforce
will leave the cr/lf alone. Then check out the scripts, do a d2u on them,
and check them back in.
$ p4 edit -t binary myscript.sh
I believe this is what I will end up being forced to do. Many of
On Wed, 27 Sep 2006, Malcolm Nixon wrote:
Jonathan Arnold wrote:
You can change the Perforce filetype to be binary, and that way Perforce
will leave the cr/lf alone. Then check out the scripts, do a d2u on them,
and check them back in.
$ p4 edit -t binary myscript.sh
I believe this
Larry Hall (Cygwin) wrote:
But what you've described so far isn't adding up and my guess is
you're going to have to offer a more convincing argument based
on detailed facts relevant to the problem you're having to sway
the hearts and minds of those who do the work.
I guess I have been somewhat
-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
Malcolm Nixon wrote:
Larry Hall (Cygwin) wrote:
But what you've described so far isn't adding up and my guess is
you're going to have to offer a more convincing argument based
on detailed facts relevant to the problem you're having to sway
the hearts and minds of those who do the work.
I
From: Eric Blake
Sent: Wednesday, September 27, 2006 8:14 PM
Subject: Re: Bash 3.1.17(8) CR/LF problem
[snip]
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
22 matches
Mail list logo
