Re: "setopt noexec" and interactive shells

[Zefram <zefram@xxxxxxxx>]

Bart Schaefer wrote:
>I've noticed that bash won't honor "set -n" when the shell is interactive;
>but zsh will happily do so, leaving you with a useless prompt.

Experimentally, bash 2.04.12 does honour "set -n" fully.

>Perhaps a happy compromise would be to force "setopt exec" just before
>executing precmd?  Any reason to test e.g. `!justonce' before doing this?

I just think it's a bad idea.  "set -n" has perfectly well-defined
semantics, and we shouldn't ignore those semantics just because it's
probably not what the user wanted.  "set -n" is not fundamentally
incompatible with interactivity.

>Having just typo'd "set -n ..." for "sed -n ...",

Tee hee.  Of course, you could equally well have typoed "kill -9 $$"
for "kill -9 $!".

>+		opts[EXECOPT] = 1;

And if you're going to ignore "set -n", this is the wrong way to do it.
pdksh 5.2.12 does effectively ignore "set -n" interactively, but it
does this by allowing the option to be set (such that "n" appeans in
$-) but then ignoring the option's state if interactive.  Actually,
its condition for overriding is that the shell is interactive and the
default conditions for interactivity on startup were met -- a shell that's
explicitly made interactive when it would not otherwise have been does
honour "set -n" fully.

The other way to do this correctly -- other than ignoring it the way
pdksh does, that is -- is to make the option unsettable, like -i, under
the appropriate circumstances.  Silent resetting is not good.

-zefram