Re: [PATCH v2 2/2] sh-setup: explicitly mark CR as a field separator

Junio C Hamano [off-list ref] writes:

Matthieu Moy [off-list ref] writes:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

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/