Re: Re: ash bug

Jean,

> >    - ash doesn't ignore the sequence, it simply implements it
> >      wrong. It does the redirection before printing the debug output
> >      in evalcommand().
>
>
> I don't know whether this has any other side effects, but if I simply
> move the redirection behind the debug output the small script works as
> expected.
>
> --- ash.c       Tue Jul 29 09:15:17 2003
> +++ ash.c.new   Wed Jul 30 21:32:42 2003
> @@ -3248,9 +3248,6 @@
>         if (iflag && funcnest == 0 && argc > 0)
>                 lastarg = nargv[-1];
>  
> -       expredir(cmd->ncmd.redirect);
> -       status = redirectsafe(cmd->ncmd.redirect, REDIR_PUSH);
> -
>         path = vpath.text;
>         for (argp = cmd->ncmd.assign; argp; argp = argp->narg.next) {
>                 struct strlist **spp;
> @@ -3279,6 +3276,9 @@
>                 out2c('\n');
>                 flushall();
>         }
> +
> +       expredir(cmd->ncmd.redirect);
> +       status = redirectsafe(cmd->ncmd.redirect, REDIR_PUSH);
>  
>         cmd_is_exec = 0;
>         spclbltin = -1;

Forward from Herbert Hu:


ash's behaviour is correct.  POSIX imposes no restrictions on this.
Even with the patch, you will still see no output if you did

set -x
{
        do stuff
} 2> /dev/null
set +x


>> I don't know whether this has any other side effects, but if I simply
>> move the redirection behind the debug output the small script works as
>> expected.


This is wrong.  It generates errors with the command

/bin/nosuchfile 2> /dev/null

* End forward *


--w
vodz