RE: t0025 weird behaviour on NonStop ksh/bash

From

Randall S. Becker <rsbecker@nexbridge.com>

Date

May 9, 2015, 03:11 UTC

Message-ID

<004e01d08a05$d6d77b60$84867220$@nexbridge.com>

In-Reply-To

<xmqqbnhuihv9.fsf@gitster.dls.corp.google.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?