Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> 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).
