From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2863 invoked from network); 27 Mar 2001 18:09:15 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 27 Mar 2001 18:09:15 -0000 Received: (qmail 7686 invoked by alias); 27 Mar 2001 18:09:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13797 Received: (qmail 7669 invoked from network); 27 Mar 2001 18:09:05 -0000 Subject: Re: "setopt noexec" and interactive shells In-Reply-To: <1010325225123.ZM10966@candle.brasslantern.com> from Bart Schaefer at "Mar 25, 2001 10:51:22 pm" To: Bart Schaefer Date: Tue, 27 Mar 2001 19:09:04 +0100 (BST) 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: >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