Hi Junio, On Thu, 4 May 2017, Junio C Hamano wrote:
> 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. Let me repeat myself: `cat` is a Unix utility. Unix line endings are LF-only. So when you say "platform whose eol convention is CRLF", you speak about a platform that is not Unix. If you want to run `cat` on Linux, you have to have a Unix-y environment. Ergo: LF-only line endings. The real problem arises only because I decided to ship Git for Windows with a POSIX emulating environment to execute the Unix shell and Perl scripts. The real solution would have been to push harder for "builtinification", but you know yourself how hard of an uphill effort that is, as the idea is still prevalent that having a large part of Git be implemented as shell/Perl scripts is not only okay, but even a Good Thing (and portability is then a matter of making every contributor know what constructs are portable and to avoid, say, Bashisms or GNU sed's options that are incompatible with BSD sed's options). Ciao, Dscho
