bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (maybe) zsh-related bug in tests/defs.in


From: Ralf Wildenhues
Subject: Re: (maybe) zsh-related bug in tests/defs.in
Date: Mon, 24 Aug 2009 23:59:04 +0200
User-agent: Mutt/1.5.20 (2009-08-09)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]