Re: "setopt noexec" and interactive shells

[Zefram <zefram@xxxxxxxx>]

Bart Schaefer wrote:
>There's no way to make the option un-, or rather re-, settable because
>once you're not executing commands the state of the shell is effectively
>frozen.

By "unsettable" I meant that the shell does not permit one to change
the state of the option.  The point is that the shell complains, rather
than giving the superficial appearance of success.  Try "set +i" in an
interactive shell for an example of the kind of behaviour I was proposing
for "set -n".

>So the closest thing to "default conditions for interactivity on startup"
>is isatty(0).

By "default conditions ..." I meant also the conditions involving
arguments given to the shell (a shell script normally executes
non-interactively regardless of ttys).  All conditions, in fact, other
than shell options (-i).  It should also be tested and stored on startup,
where we already have the logic (albeit in a twisted form), rather than
trying to reconstruct it after the fact.

But the ksh semantics aren't very good.  I'd be happier with simpler
semantics, that NO_EXEC is ineffective iff INTERACTIVE is on.

I'm basically happy with your patch (or the revised version) in
that it retains the state of NO_EXEC and simply denies it effect,
the way ksh does.  I'd still prefer a noisy refusal to set NO_EXEC,
as I proposed above.

>+	    if (unset(EXECOPT) && (unset(INTERACTIVE) || !isatty(0)))

As I suggested above, I'd prefer that that condition be

	    if (unset(EXECOPT) && unset(INTERACTIVE))

-zefram