From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18138 invoked from network); 5 Mar 2001 01:56:02 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Mar 2001 01:56:02 -0000 Received: (qmail 17119 invoked by alias); 5 Mar 2001 01:55:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13564 Received: (qmail 17108 invoked from network); 5 Mar 2001 01:55:56 -0000 Subject: Re: "setopt noexec" and interactive shells In-Reply-To: <1010304052058.ZM13951@candle.brasslantern.com> from Bart Schaefer at "Mar 4, 2001 05:20:57 am" To: Bart Schaefer Date: Mon, 5 Mar 2001 01:55:51 +0000 (GMT) CC: zsh-workers@sunsite.dk X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram 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