Zsh Mailing List Archive
Messages sorted by:
Re: "setopt noexec" and interactive shells
- X-seq: zsh-workers 13564
- From: Zefram <zefram@xxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: "setopt noexec" and interactive shells
- Date: Mon, 5 Mar 2001 01:55:51 +0000 (GMT)
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <1010304052058.ZM13951@xxxxxxxxxxxxxxxxxxxxxxx> from Bart Schaefer at "Mar 4, 2001 05:20:57 am"
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
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.
Messages sorted by: