RE: t0025 weird behaviour on NonStop ksh/bash

RE: t0025 weird behaviour on NonStop ksh/bash

[Randall S. Becker]

On May 8, 2015 7:17 PM , I wrote in my haste:
> 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?

Digging deeper, this appears to be is Yet Another Platform Problem. There
are more '\r' characters sneaking about beyond just echo. I am taking it up
with other developers to see whether we can track down where the offending
'\r' characters are coming from. They do not appear to be from git or its
tests at this stage

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.

.

t0025 weird behaviour on NonStop ksh/bash

[Randall S. Becker]

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?

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.

Re: t0025 weird behaviour on NonStop ksh/bash

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

> 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?

RE: t0025 weird behaviour on NonStop ksh/bash

[Randall S. Becker]

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 :(.