Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Am 5/22/2014 15:19, schrieb David Kastrup: >> Torsten Bögershausen <tboegi@xxxxxx> writes: >> >>> On 2014-05-22 14.48, Elia Pinto wrote: >>>> Found by check-non-portable-shell.pl >>> >>> Thanks for picking this up >>>> -export TEST_DIRECTORY=$(pwd)/../../../t >>>> +TEST_DIRECTORY=$(pwd)/../../../t && export TEST_DIRECTORY >>> Minor remark: >>> Both commands should go on their own line, like this: >>> >>> TEST_DIRECTORY=$(pwd)/../../../t && >>> export TEST_DIRECTORY >>> >>> >>> And, unrelated to this patch, >>> there seem to be a lot of && missing in git-remote-testgit.sh. >> >> I have a hard time taking the above && seriously. pwd is a shell >> builtin (when we are not talking about Version 3 UNIX or something) that >> can hardly fail. And when your shell does not support assignment to a >> shell variable, you'll have a hard time getting the shell script to run. > > The && after an assignment makes a big difference when the assignment is > part of an && chain. This is *very* common in our test suite, as you know. > > People tend to copy-and-paste. And then it is better to provide a more > universally applicable precedent. Copy-and-paste will not magically add the second && that would be required for that usage, and the one in the line above might mislead you into thinking that the problem "has been dealt with already". So I'm not convinced that using && outside of a preexisting && chain makes any sense in this context. -- David Kastrup -- 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