One additional thing I'd like to say, if people are considering
possibly making a decision based off the line ending of the first line
of the file: it's worth bearing in mind that it's quite possible for a
file to end up with mixed line endings. Most editors are at least
smart enough to convert th
Eric Blake wrote:
There is also the possibility of making bash turn igncr on by default, but
/bin/sh leaving it off, since only /bin/sh is specified by POSIX; but that
also gives me the willies thinking about people who will complain why
their script doesn't work when they change from #!/bin/bash
> There are a few other things to think about with your initial attempt.
> Right now, igncr is an all or nothing setting, can be inherited into child
> processes via SHELLOPTS, but can only be changed by explicit user action.
> Your patch only ever turns it on without user intervention, not off.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Lewis Hyatt on 10/25/2006 1:48 PM:
> Below is a patch to shell.c which implements my suggestion (It is just the
> output of diff -u, is that OK? The patch is relative to the 3.2-4 version.) I
> just modified the open_shell_script() functio
> Propose a patch, and I will consider it. In my opinion, it was much
> easier to do igncr as an all or none option than it was to parse the first
> line and discard \r on a per-file basis, not to mention that all-or-none
> is easily configurable so that those of us who WANT literal \r as required
> From: Eric Blake
> Sent: Tuesday, October 24, 2006 7:03 PM
> Subject: Re: igncr vs text mode mounts, performance vs compatibility
>
> According to Lewis Hyatt on 10/24/2006 12:57 PM:
> > Just a thought, it would probably solve 99% of people's problems if
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Lewis Hyatt on 10/24/2006 12:57 PM:
> Just a thought, it would probably solve 99% of people's problems if you just
> specified that if the first line of the script ends in \r\n, then \r will be
> ignored for the rest of the file. Then you
> >> Are you saying that these people expect bash to treat CRLF as if the
> >> CR were non-whitespace? Can you give me an example where this would
> >> be a useful feature?
>
> It may not be a well-used feature, but I won't go so far as to call it not
> useful. One possible use - a script writte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Rob Walker on 10/18/2006 6:38 PM:
> I looked into my scripts a little harder, have better results, some new
> conclusions:
Rob, please avoid http://cygwin.com/acronyms/#TOFU.
Thanks for calculating some timings.
>
> ---
Thanks for reading, Brian. Apologies to all that my recent tend to bulk.
The point of my post was to advocate igncr as the default for bash 3. I
realize I'm not alone in this advocacy. I'm truly happy that bash 3 is
super fast compared to bash 2, but bash 3's "incompatibility" is
currently
On Wed, Oct 18, 2006 at 09:50:00PM -0400, Larry Hall (Cygwin) wrote:
>Brian Dessent wrote:
>>Rob Walker wrote:
>>
>>>I looked into my scripts a little harder, have better results, some new
>>>conclusions:
>>
>>I think you are missing the point somewhat. The thing you need to
>>benchmark against is
Brian Dessent wrote:
Rob Walker wrote:
I looked into my scripts a little harder, have better results, some new
conclusions:
I think you are missing the point somewhat. The thing you need to
benchmark against is the older bash version before the 'igncr' option
even existed, which read every s
Rob Walker wrote:
> I looked into my scripts a little harder, have better results, some new
> conclusions:
I think you are missing the point somewhat. The thing you need to
benchmark against is the older bash version before the 'igncr' option
even existed, which read every script one byte at a t
I looked into my scripts a little harder, have better results, some new
conclusions:
-
line ending | mount mode | igncr | "user" time
-
CRLF | text | set | 1.0114s
---
14 matches
Mail list logo
