Possible bug in zsh

Possible bug in zsh

[Vincent Stemen]

I think I may have encountered a bug in Z shell.  It began when I
tried linking /bin/sh to zsh on FreeBSD-5.1.  When it reboots, I get a
lot of errors from the init scripts because the rootfs does not get
re-mounted read-writable.  I have isolated the piece of init script
code and included a small script below, extracted from the init
scripts and modified for testing, that reproduces the problem.  See
the comments in the script.

The problem goes away if I remove the [ -n "$_precmd" ] statement
which, so far as I can tell, should have no effect on the following if
statement where the problem is.  I tested with zsh-4.0.9 and
zsh-4.1.0.dev5.


<script>

root_start()
{
    # This function normally remounts / in rw mode
    echo "<< Running root_start() >>"
}


_cmd=root_start

if [ -n "$_cmd" ]; then
            # if the precmd failed and force
            # isn't set, exit
            #

    # Remove or comment out these two lines and the problem goes away.
    # ie. zsh does not return 1 in the next statement.
    [ -n "$_precmd" ] &&
        echo "run_rc_command: evaluating ${_precmd}()."

    # $_precmd is null.
    # zsh enters this if statement and returns 1, causing root_start() to
    # never get run, thus leaving /
    # mounted ro.  FreeBSD's sh and bash do not.

    if ! eval $_precmd && [ -z "$rc_force" ]; then
        return 1
    fi

    [ -n "$_cmd" ] &&
        echo "run_rc_command: evaluating ${_cmd}()."
    if ! eval $_cmd && [ -z "$rc_force" ]; then
        return 1
    fi

    return 0
fi

</script>

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
http://www.InetAddresses.net

Re: Possible bug in zsh

[Wayne Davison]

On Mon, Dec 29, 2003 at 02:02:22AM -0600, Vincent Stemen wrote:
> I think I may have encountered a bug in Z shell.

Here's a simplified test case that better shows what's gone wrong:

false; if eval ''; then echo one; fi
true; if eval ''; then echo two; fi

This outputs only "two" in zsh, but both "one" and "two" in bash.  It
appears that an eval of an empty string in zsh returns the return code
of the last-run command.  In your example script, the "[ -n ...]" part
failed, so the following "if ! eval $empty ..." bit was executed as if
the eval of the empty string had also failed.  I also assume that this
is a bug.

..wayne..

Re: Possible bug in zsh

[Wayne Davison]

On Mon, Dec 29, 2003 at 01:21:22AM -0800, Wayne Davison wrote:
> false; if eval ''; then echo one; fi    [...fails...]
> true; if eval ''; then echo two; fi     [...succeeds...]

I'm hoping that someone more familiar with the exec internals will jump
in here, but in the meantime, here's the change I made back on Monday to
fix this bug:

--- Src/builtin.c	13 Nov 2003 14:34:38 -0000	1.109
+++ Src/builtin.c	29 Dec 2003 09:50:52 -0000
@@ -4155,6 +4155,7 @@
 	errflag = 0;
 	return 1;
     }
+    lastval = 0;
     execode(prog, 1, 0);
     if (errflag) {
 	lastval = errflag;

I'm not sure it's the best fix, though, as it might be better to change
one of the lower functions down in the execode() calling chain instead
of changing bin_eval().  It does fix the bug, though.

..wayne..

Re: Possible bug in zsh

[James Devenish]

In message <20040101233856.GA13263@blorf.net>
on Thu, Jan 01, 2004 at 03:38:56PM -0800, Wayne Davison wrote:
> On Mon, Dec 29, 2003 at 01:21:22AM -0800, Wayne Davison wrote:
> > false; if eval ''; then echo one; fi    [...fails...]
> > true; if eval ''; then echo two; fi     [...succeeds...]
> 
> I'm hoping that someone more familiar with the exec internals will jump
> in here, but in the meantime, here's the change I made back on Monday to
> fix this bug:

Is it really a bug? Doesn't ksh offer this as the preferred behaviour by
default in the absence of the 'posix' option? But it seems like an
oversight that zsh doesn't give you the ability to have the POSIX
behaviour. Perhaps this is one of the featurebugs that makes zsh
unsuitable as /bin/sh. Some zsh scripts might depend on zsh's current
behaviour.

Re: Possible bug in zsh

[Vincent Stemen]

On Thu, Jan 01, 2004 at 03:38:56PM -0800, Wayne Davison wrote:
> On Mon, Dec 29, 2003 at 01:21:22AM -0800, Wayne Davison wrote:
> > false; if eval ''; then echo one; fi    [...fails...]
> > true; if eval ''; then echo two; fi     [...succeeds...]
> 
> I'm hoping that someone more familiar with the exec internals will jump
> in here, but in the meantime, here's the change I made back on Monday to
> fix this bug:
> 
> --- Src/builtin.c	13 Nov 2003 14:34:38 -0000	1.109
> +++ Src/builtin.c	29 Dec 2003 09:50:52 -0000
> @@ -4155,6 +4155,7 @@
>  	errflag = 0;
>  	return 1;
>      }
> +    lastval = 0;
>      execode(prog, 1, 0);
>      if (errflag) {
>  	lastval = errflag;
> 
> I'm not sure it's the best fix, though, as it might be better to change
> one of the lower functions down in the execode() calling chain instead
> of changing bin_eval().  It does fix the bug, though.
> 
> ..wayne..

Thanks for the responses Wayne.  I will archive this in case I need it
in the future.  For now, it looks like there are also other
incompatibilities in running the init scripts (well, at least one so
far) that also prevent using zsh as sh in FreeBSD.  So, I think I will put
that idea on hold for now and stick with the native /bin/sh.

I temporarily modified the init script code which got around the eval
problem and discovered that some of the scripts use "set -T" which is not
implemented in zsh.  The FreeBSD sh man page says this about it.

<manual>

-T trapsasync

    When waiting for a child, execute traps immediately.  If this option
    is not set, traps are executed after the child exits, as specified in
    IEEE Std 1003.2 (``POSIX.2'') This nonstandard option is useful for
    putting guarding shells around children that block signals.  The
    surrounding shell may kill the child or it may just return control to
    the tty and leave the child alone, like this:

        sh -T -c "trap 'exit 1' 2 ; some-blocking-program"

</manual>

Regards,
Vincent

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
http://www.InetAddresses.net