Hello Stefano, thanks for the report.
* Stefano Lattarini wrote on Sun, Aug 23, 2009 at 10:46:47PM CEST: > I found what follows using the latest automake from the git > repository, on my debian unstable system. > > While trying to run the automake testsuite *in parallel*, using > zsh (version 4.3), I ran into some apparently random failures > (with most test scripts failing), which I tracked down to the > way $testSubDir is defined in `tests/defs.in'. Can you please specify how exactly you ran the tests using zsh, or got the build system to run the tests for you using zsh, and which zsh version you are using? Because if /bin/sh is zsh, or a symlink to zsh, then it should turn on 'emulate sh' mode all by itself already there (zsh checks its $0 on startup for matching 'sh' or 'ksh). If you do something like zsh $srcdir/all.test to run a test manually using zsh, then of course this won't work. But in that case I'd advise you to either not use zsh, or to add a symlink of the form ln -s /path/to/zsh ./sh ./sh $srcdir/all.test If you instead do something like make check SHELL=/path/to/zsh then that should have already failed much earlier: some of the constructs in the makefiles require sh emulation. > By default, in a sourced script, zsh set $0 to the path of that > same sourced script -- more info at: > http://zsh.dotsrc.org/Doc/Release/Parameters.html#IDX166 > This problem *seems* to be taken care of in `defs.in' itself, by the > command `emulate sh', but unfortunately this command is issued > too late. > > In fact, when `foo.test' includes `./defs', it isn't in "emulate sh" > mode yet, so that in `./defs' tha value of $0 remains set to > `./defs', no matter if the sh-compatibility mode is later > activated. Thus $me is *always* set to `defs' and $testSubDir > is *always* set to `defs.dir'. D'oh. Ouch. Is there some zsh variable that retains the original name of the script? > I'm not sure if this can be truly classified as a bug, since the > test scripts all have a `#!/bin/sh' shebang line, and I hope > that few people or systems are crazy enough to use zsh as > their default Bourne shell. Anyway, this problem might deserve > some consideration. Again I'm not yet convinced this happens in a real-world situation, but if it does, one thing we could do would be to check whether $0 is ./defs or ./defs-p, and in that case add $$ or $RANDOM to allow for parallel builds to work. Cheers, Ralf
