Junio C Hamano <gits...@pobox.com> writes:
> Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
>
>> Johannes Schindelin <johannes.schinde...@gmx.de> writes:
>>
>>> This is the correct thing to do, really: we already specify LF as
>>> field separator.
>>
>> I'm almost convinced that this is the right thing to do in the long run
>> ("almost" because I'm not sure, not because I have arguments against). I
>> agree with Junio that the commit message should be more convincing, but
>> indeed, accepting LF and not CR is strange.
>
> If there were a single character that denotes CRLF, I'd say that
> including such a character in IFS would make sense on a system with
> CRLF EOL convention. But that is not the case.
It's not, but there are platforms where the newline convention is
CR-only. AFAIK, they are all "old" architectures (like Mac OS < X), but
there are still CR-only files lying around.
> * read is not the only user of IFS. Expressing "list of things"
> (pre bashism "shell array" days) by concatenating elements into a
> single string variable, separated with LF, and later iterating
> over them is a very common use case, e.g.
>
> LF='
> '
> list="$thing1"
> list="$list$LF$thing2"
> list="$list$LF$thing3"
> ...
>
> IFS=$LF
> for thing in $list
> do
> ...
>
> And including LF by default in IFS, especially when "things" can
> contain SP/HT, is handy.
I don't get the argument. You're talking about a case where you
explicitly set IFS, and the patch is about changing the default. The
use-case above would work exactly like before if we modify the default
IFS.
> If you
> have a variable in which "A^MB" is there, "set $variable" would
> split them into two and assign B to $2, which is not what the
> scripts would expect.
The same goes if you replace ^M with a tab or a space. Using unquoted
"set $variable" is sane only if you are sure that $variable does not
contain unexpected special characters. I can't imagine a case where one
would accept space, tab or LF as separator and would need to accept CR
as a non-separator.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
