{"thread":{"id":"39280","subject":"t0025 weird behaviour on NonStop ksh/bash","startedAt":"2015-05-08T23:17:28Z","lastAt":"2015-05-09T03:11:26Z","messageCount":3,"participants":["Randall S. Becker","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"260880","messageId":"003101d089e5$27347610$759d6230$@nexbridge.com","threadId":"39280","inReplyTo":null,"subject":"t0025 weird behaviour on NonStop ksh/bash","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-05-08T23:17:28Z","receivedAt":"2015-05-08T23:17:28Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Ok, I'm sure that this is not a git problem, but there is an assumption\nabout echo behaviour in t0025 that may not be correct. When executed from a\nshell function on the HP NonStop platform under ksh and bash, the LFonly\nfile annoyingly contains cr-lf not just lf. This causes sub-test 4 to fail.\nWeirdly, this does not happen from an interactive shell. My proposed\nsolution, in t0025-crlf-auto.sh, to this is to make it explicit that bad\nbehaviour on the part of echo should be dealt with severely, as in:\n\n        for w in Hello world how are you; do echo $w; done | tr -d '\\r'\n>LFonly\n\ninstead of \n\n        for w in Hello world how are you; do echo $w; done >LFonly\n\nwhich is a no-op on platforms that behave themselves in this situation. Is\nthis the proper approach?\n\nCheers,\nRandall\n\n-- Brief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)/NonStop(211288444200000000)\n-- In my real life, I talk too much.\n"},{"id":"260888","messageId":"xmqqbnhuihv9.fsf@gitster.dls.corp.google.com","threadId":"39280","inReplyTo":"003101d089e5$27347610$759d6230$@nexbridge.com","subject":"Re: t0025 weird behaviour on NonStop ksh/bash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-09T02:50:50Z","receivedAt":"2015-05-09T02:50:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n\n> Ok, I'm sure that this is not a git problem, but there is an assumption\n> about echo behaviour in t0025 that may not be correct. When executed from a\n> shell function on the HP NonStop platform under ksh and bash, the LFonly\n> file annoyingly contains cr-lf not just lf. This causes sub-test 4 to fail.\n> Weirdly, this does not happen from an interactive shell. My proposed\n> solution, in t0025-crlf-auto.sh, to this is to make it explicit that bad\n> behaviour on the part of echo should be dealt with severely, as in:\n>\n>         for w in Hello world how are you; do echo $w; done | tr -d '\\r'\n>>LFonly\n>\n> instead of \n>\n>         for w in Hello world how are you; do echo $w; done >LFonly\n>\n> which is a no-op on platforms that behave themselves in this situation. Is\n> this the proper approach?\n\nWhy on earth does \"echo $w\" that prints just ASCII alphabet and\nnothing else (other than the end-of-line, of course) gives CRLF\nin the first place?\n\nIs stripping with \"tr -d\" a sane approach?  I am not sure if it is\ntackling the right problem.\n\nBecause we use 'echo', expecting it to behave sensibly in many other\nplaces, wouldn't it be the case that all your 'tr -d' here does is\nto add an unnecessary pipe on sane platforms for this single test\nscript, while leaving all the other uses of 'echo' in other shell\nscripts, including scripted Porcelains like 'git pull', broken on\nyour platform?\n"},{"id":"260890","messageId":"004e01d08a05$d6d77b60$84867220$@nexbridge.com","threadId":"39280","inReplyTo":"xmqqbnhuihv9.fsf@gitster.dls.corp.google.com","subject":"RE: t0025 weird behaviour on NonStop ksh/bash","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-05-09T03:11:26Z","receivedAt":"2015-05-09T03:11:26Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 8, 2015 10:51 PM Junio C Hamano wrote:\n> > Ok, I'm sure that this is not a git problem, but there is an\n> > assumption about echo behaviour in t0025 that may not be correct. When\n> > executed from a shell function on the HP NonStop platform under ksh\n> > and bash, the LFonly file annoyingly contains cr-lf not just lf. This\ncauses sub-\n> test 4 to fail.\n> > Weirdly, this does not happen from an interactive shell. My proposed\n> > solution, in t0025-crlf-auto.sh, to this is to make it explicit that\n> > bad behaviour on the part of echo should be dealt with severely, as in:\n> >\n> >         for w in Hello world how are you; do echo $w; done | tr -d '\\r'\n> >>LFonly\n> >\n> > instead of\n> >\n> >         for w in Hello world how are you; do echo $w; done >LFonly\n> >\n> > which is a no-op on platforms that behave themselves in this\n> > situation. Is this the proper approach?\n> Why on earth does \"echo $w\" that prints just ASCII alphabet and nothing\nelse\n> (other than the end-of-line, of course) gives CRLF in the first place?\n> \n> Is stripping with \"tr -d\" a sane approach?  I am not sure if it is\ntackling the right\n> problem.\n> \n> Because we use 'echo', expecting it to behave sensibly in many other\nplaces,\n> wouldn't it be the case that all your 'tr -d' here does is to add an\nunnecessary\n> pipe on sane platforms for this single test script, while leaving all the\nother\n> uses of 'echo' in other shell scripts, including scripted Porcelains like\n'git pull',\n> broken on your platform?\n\nAbsolutely agree. This (being the test case) is not the problem and adding\ntr -d is not a viable solution even if it appears to fix the issue at this\nmoment in time. Built-in and variable processing need to behave in a\nnormalized manner. I'm working to get that resolved; however, actually doing\na proper fix happens to be outside of my control :(.\n"}]}