"setopt noexec" and interactive shells

"setopt noexec" and interactive shells

[Bart Schaefer]

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.

Having just typo'd "set -n ..." for "sed -n ...", I'm acutely aware of the
problems with this.  I briefly considered adding "setopt exec" to precmd,
until I thought about it for an additional second.

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

Index: Src/init.c
===================================================================
--- Src/init.c	2001/01/16 17:18:09	1.70
+++ Src/init.c	2001/03/04 05:19:50
@@ -114,6 +114,7 @@
 	    if (interact) {
 	        int hstop = stophist;
 		stophist = 3;
+		opts[EXECOPT] = 1;
 		preprompt();
 		stophist = hstop;
 	    }

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: "setopt noexec" and interactive shells

[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

Re: "setopt noexec" and interactive shells

[Bart Schaefer]

On Mar 5,  1:55am, Zefram wrote:
} Subject: Re: "setopt noexec" and interactive shells
}
} pdksh 5.2.12 does effectively ignore "set -n" interactively, but [...]
} 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.

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.  If ignoreeof is also set, it's painful even to exit.

So the closest thing to "default conditions for interactivity on startup"
is isatty(0).  This could of course be fooled by "exec < /dev/tty" or some
such, but if someone is willing to go to that much effort to simulate an
interactive startup ...

Any comments on this patch?

Index: Src/exec.c
===================================================================
--- Src/exec.c	2001/03/24 22:19:24	1.128
+++ Src/exec.c	2001/03/25 22:14:08
@@ -2092,7 +2092,7 @@
 		zwarn("writing redirection not allowed in restricted mode", NULL, 0);
 		execerr();
 	    }
-	    if (unset(EXECOPT))
+	    if (unset(EXECOPT) && (unset(INTERACTIVE) || !isatty(0)))
 		continue;
 	    switch(fn->type) {
 	    case REDIR_HERESTR:


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: "setopt noexec" and interactive shells

[Bart Schaefer]

On Mar 25, 10:51pm, Bart Schaefer wrote:
}
} Any comments on this patch?

Ahem.  I have my own comment:  It doesn't work.  I missed another spot
where EXECOPT is tested.  Critique the following patch instead.


Index: Src/exec.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/exec.c,v
retrieving revision 1.128
diff -c -r1.128 exec.c
--- Src/exec.c	2001/03/24 22:19:24	1.128
+++ Src/exec.c	2001/03/25 22:59:12
@@ -1639,7 +1639,7 @@
     char *text;
     int save[10];
     int fil, dfil, is_cursh, type, do_exec = 0, i, htok = 0;
-    int nullexec = 0, assign = 0, forked = 0;
+    int nullexec = 0, assign = 0, forked = 0, execopt;
     int is_shfunc = 0, is_builtin = 0, is_exec = 0;
     /* Various flags to the command. */
     int cflags = 0, checked = 0;
@@ -1648,6 +1648,7 @@
     Wordcode beg = state->pc, varspc;
     FILE *oxtrerr = xtrerr;
 
+    execopt = !(unset(EXECOPT) && (unset(INTERACTIVE) || !isatty(0)));
     doneps4 = 0;
     redir = (wc_code(*state->pc) == WC_REDIR ? ecgetredirs(state) : NULL);
     if (wc_code(*state->pc) == WC_ASSIGN) {
@@ -2092,7 +2093,7 @@
 		zwarn("writing redirection not allowed in restricted mode", NULL, 0);
 		execerr();
 	    }
-	    if (unset(EXECOPT))
+	    if (!execopt)
 		continue;
 	    switch(fn->type) {
 	    case REDIR_HERESTR:
@@ -2218,7 +2219,7 @@
 	    fputc('\n', xtrerr);
 	    fflush(xtrerr);
 	}
-    } else if (isset(EXECOPT) && !errflag) {
+    } else if (execopt && !errflag) {
 	/*
 	 * We delay the entersubsh() to here when we are exec'ing
 	 * the current shell (including a fake exec to run a builtin then

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: "setopt noexec" and interactive shells

[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

Re: "setopt noexec" and interactive shells

[Zefram]

Oh, and whichever way it's implemented in the end, it'll have to be
documented.  Something like "This option has no effect if INTERACTIVE
is on." in the EXEC entry in zshoptions(1), obviously varying according
to the semantics that are eventually implemented.

-zefram

Re: "setopt noexec" and interactive shells

[Bart Schaefer]

On Mar 27,  8:12pm, Zefram wrote:
}
} Oh, and whichever way it's implemented in the end, it'll have to be
} documented.

I played around a bit with the most recent patch (13756) as adjusted to
remove the isatty(0) test.  It had some unexpected side-effects, one of
which was that `zpty' commands were not executed (because `interactive'
is not set in the subshell whose i/o is the pty slave).

So I've concluded that preserving but selectively ignoring the state of
the option is at least as bad as silently resetting it.

The other alternative that Zefram suggested was noisily refusing to change
the option:

Index: Src/options.c
===================================================================
--- Src/options.c	2001/02/28 17:05:08	1.22
+++ Src/options.c	2001/03/30 05:24:38
@@ -647,6 +647,9 @@
 	    for (s = rparams; *s; s++)
 		restrictparam(*s);
 	}
+    } else if(!force && optno == EXECOPT && !value && interact) {
+	/* cannot set noexec when interactive */
+	return -1;
     } else if(!force && (optno == INTERACTIVE || optno == SHINSTDIN ||
 	    optno == SINGLECOMMAND)) {
 	if (opts[optno] == value)

With the above patch, `zsh -n' can still give you a useless prompt, but
`set -n' etc. within the shell will complain:

zagzig% set -n
set: can't change option: -n
zagzig% setopt noexec
setopt: can't change option: noexec

Any remaining objections?

Index: Doc/Zsh/options.yo
===================================================================
--- Doc/Zsh/options.yo	2001/03/19 02:32:20	1.47
+++ Doc/Zsh/options.yo	2001/03/30 06:35:08
@@ -374,6 +374,8 @@
 item(tt(EXEC) (tt(PLUS()n), ksh: tt(PLUS()n)) <D>)(
 Do execute commands.  Without this option, commands are
 read and checked for syntax errors, but not executed.
+This option cannot be turned off in an interactive shell,
+except when `tt(-n)' is supplied to the shell at startup.
 )
 pindex(EXTENDED_GLOB)
 cindex(globbing, extended)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: "setopt noexec" and interactive shells

[Bart Schaefer]

On Mar 27,  7:09pm, Zefram wrote:
} Subject: Re: "setopt noexec" and interactive shells
}
} 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.

Aha.  But, unlike `interactive', there's no reason not to allow `noexec'
to become set in a shell function, provided that it's going to be restored
again by `localoptions' when the function exits.

That was why my original (some weeks ago) patch reset the option just
before the prompt was printed, rather than disabling it at some lower
level.

} 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.
} 
} As I suggested above, I'd prefer that that condition be
} 
} 	    if (unset(EXECOPT) && unset(INTERACTIVE))

That's fine with me, too, but I'd still like to hear any thoughts you
have on making `noexec' work within a shell function.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: "setopt noexec" and interactive shells

[Zefram]

Bart Schaefer wrote:
>Aha.  But, unlike `interactive', there's no reason not to allow `noexec'
>to become set in a shell function, provided that it's going to be restored
>again by `localoptions' when the function exits.

*grumble*.  What's anyone ever going to use noexec for other than syntax
checking?  I'd prefer that we give the option a consistent behaviour.
For the record, pdksh makes no such distinction between commands in a
function and commands at the top level:

$ foo () { echo foo $-; set -n; echo bar $-; }
$ echo foo $-
foo ims
$ foo
foo ims
bar imns
$ echo bar $-
bar imns

-zefram

Re: "setopt noexec" and interactive shells

[Bart Schaefer]

On Mar 27,  8:25pm, Zefram wrote:
} Subject: Re: "setopt noexec" and interactive shells
}
} *grumble*.  What's anyone ever going to use noexec for other than syntax
} checking?

Well, yes, exactly.  Isn't it possible that you'd like to check the syntax
of a function you have defined in an interactive shell?

} I'd prefer that we give the option a consistent behaviour.

The consistent behavior I was thinking of is that commands entered at a
shell prompt (e.g. through ZLE) are never affected by `noexec' whereas
all other commands are.  How is that any less consistent than, say, the
SHINSTDIN behavior we were just discussing?

} For the record, pdksh makes no such distinction between commands in a
} function and commands at the top level

Right, but ksh doesn't have `localoptions'.

I don't mean to be making too big a deal of this, but I want to be sure we
can explain/defend whatever implementation eventually results.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net