RE: t0025 weird behaviour on NonStop ksh/bash

["Randall S. Becker" <rsbecker@nexbridge.com>]

On May 8, 2015 10:51 PM Junio C Hamano wrote:
> > Ok, I'm sure that this is not a git problem, but there is an
> > assumption about echo behaviour in t0025 that may not be correct. When
> > executed from a shell function on the HP NonStop platform under ksh
> > and bash, the LFonly file annoyingly contains cr-lf not just lf. This
causes sub-
> test 4 to fail.
> > Weirdly, this does not happen from an interactive shell. My proposed
> > solution, in t0025-crlf-auto.sh, to this is to make it explicit that
> > bad behaviour on the part of echo should be dealt with severely, as in:
> >
> >         for w in Hello world how are you; do echo $w; done | tr -d '\r'
> >>LFonly
> >
> > instead of
> >
> >         for w in Hello world how are you; do echo $w; done >LFonly
> >
> > which is a no-op on platforms that behave themselves in this
> > situation. Is this the proper approach?
> Why on earth does "echo $w" that prints just ASCII alphabet and nothing
else
> (other than the end-of-line, of course) gives CRLF in the first place?
> 
> Is stripping with "tr -d" a sane approach?  I am not sure if it is
tackling the right
> problem.
> 
> Because we use 'echo', expecting it to behave sensibly in many other
places,
> wouldn't it be the case that all your 'tr -d' here does is to add an
unnecessary
> pipe on sane platforms for this single test script, while leaving all the
other
> uses of 'echo' in other shell scripts, including scripted Porcelains like
'git pull',
> broken on your platform?

Absolutely agree. This (being the test case) is not the problem and adding
tr -d is not a viable solution even if it appears to fix the issue at this
moment in time. Built-in and variable processing need to behave in a
normalized manner. I'm working to get that resolved; however, actually doing
a proper fix happens to be outside of my control :(.