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 :(. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html