Re: [PATCH 0/5] Abide by our own rules regarding line endings

From: Junio C Hamano <gitster@pobox.com>
Date: May 4, 2017, 15:04 UTC
Message-ID: <xmqq60hgacjp.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.21.1.1705041129170.4905@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

> Well, a couple of comments about your comment:
>
> - we say "shell scripts", but we're sloppy there: they are "Unix shell
>   scripts", as they are executed by Unix shells. As such, it is pretty
>   obvious that they favor Unix line endings, right? And that they do not
>   really handle anything else well, right?

Not really.  I would expect that

	cat A B C

with CRLF line endings (i.e. "cat A B C<CR><LF>") on platforms whose eol convention is LF to barf due to the missing file whose name is "C<CR>", while on platforms whose eol convention is CRLF, I do expect the contents of file C comes at the end of the output.

> - You try to say that it is not okay for shell scripts to be checked
>   out as LF-only when the platform convention for *text* files is CR/LF,
>   right?

I didn't try to and I didn't say that, I hope. I think it is not OK for shell scripts to be checked out with <CR><LF> when the platform convention for text is <LF>, though. It may be possible for an implementation on CRLF platform to tolerate missing <CR> (i.e. a file in LF convention--instead of treating a lone <LF> as a non-eol but just a regular "funny" byte, treat it as a normal eol), but that would be a quality-of-implementation thing. So when the platform convention for text files is <CR><LF>, I would have thought that it was more natural to check out shell scripts as such.

However, I did not think things through when I said "I am not sure if it is OK for shell scripts not to honor the platform convention, though." In a sense, the "cat A B C" example does not have to worry about the platform convention issue very much. In real scripts, we have things like a string literal that spans lines (i.e. do we have a LF, or a CRLF pair, in between these two lines?) and here documents (ditto). To handle these "correctly" while treating shell scripts mere "text" files, a shell implementation on CRLF platform has to accept CRLF, pretend as if it saw only LF, do all the processing as if the eol convention were LF, and convert LF in the output from the script to CRLF. I think that is _too_ much to ask for an implementation, and such an attempt would get corner cases wrong. IOW, I was not sure if it is OK for scripts not to honor the platorm convention when I wrote the message you are responding to, but I think it probably is not just OK but is the simplest/cleanest for shell implementations not to honor the platform convention and instead pretend that they always live in LF-only world.

And all of the above ultimately does not matter. If the shell you have on Windows cannot take CRLF files, then our shell script must be checked out as LF files even on Windows. My "I am not sure" was mostly from not knowing how ingrained that "cannot take CRLF files" was (i.e. I didn't know if there may be some knobs similar to core.crlf we have that you can toggle for your shell to honor the platform convention).