Re: [v2 PATCH] eval: Reset handler when entering a subshell

[Jilles Tjoelker <jilles@xxxxxxxx>]

On Sun, Mar 03, 2019 at 04:43:09PM +0000, Harald van Dijk wrote:
> On 03/03/2019 13:57, Herbert Xu wrote:
> > On Sat, Mar 02, 2019 at 01:28:44PM +0000, Harald van Dijk wrote:

> > > That is *a* real bug here, not *the* real bug. This leaves the buggy
> > > behaviour of the "command" built-in intact in the test case I included in
> > > the message you replied to.

> > I don't quite understand.  Could you explain what is still buggy
> > after the following patch?

> I gave this example in my previous message:

>   command . /dev/stdin <<EOF
>   set -o invalid
>   echo a
>   EOF
>   echo b

> Ordinarily, "set -o invalid" is a "special built-in utility error", for
> which the consequence is that a non-interactive shell "shall exit". If it
> weren't a special built-in utility, it would be an "other utility (not a
> special built-in) error", for which a non-interactive shell "shall not
> exit".

> The effect of the command built-in is that "if the command_name is the same
> as the name of one of the special built-in utilities, the special properties
> in the enumerated list at the beginning of Special Built-In Utilities shall
> not occur." This is ambiguous as to whether it is just about the special
> properties associated with the . command, or whether it includes those
> associated with the set command called indirectly, but it must be one or the
> other. If it includes the set command, then the shell shall not exit, and
> the correct output is a followed by b. If it does not include the set
> command, then the shell shall exit, and the correct output is nothing. dash
> outputs b, which is wrong in either case.

The way I interpret this is that any error while parsing or executing
the . or eval command(s) is a "special built-in utility error" which can
be "caught" using "command". Therefore, the correct output is an error
message about the invalid option (to stderr) followed by b. This is what
happens in FreeBSD sh (for quite a few years), ksh93 (20120801_2) and
mksh (56c).

Given that the text is somewhat ambiguous, I think bash's POSIX mode
behaviour of exiting may also be valid.

I don't like disabling the special properties of the inner set command
since this creates a different kind of script for 'command .' versus
'.'. Normally (though not in #!/bin/bash scripts), if I write something
like 'set -o pipefail', I can safely assume that it will take if the
shell continues to the next command; if the shell does not support the
option, it exits.

The fairly old dash v0.5.9.1 I tried works even differently, writing an
error message (to stderr) followed by a. So it first continues after the
error and then aborts when '.' ends. This seems clearly broken (but I
think things have changed since back then).

-- 
Jilles Tjoelker