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

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Oct 27, 2015, 10:01 UTC
Message-ID: <vpqd1w07hr7.fsf@grenoble-inp.fr>
In-Reply-To: <xmqq8u6piir8.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 15 quoted lines

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Johannes Schindelin <johannes.schindelin@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.

Show 19 quoted lines

>  * 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/