* "setopt noexec" and interactive shells @ 2001-03-04 5:20 Bart Schaefer 2001-03-05 1:55 ` Zefram 0 siblings, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2001-03-04 5:20 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-04 5:20 "setopt noexec" and interactive shells Bart Schaefer @ 2001-03-05 1:55 ` Zefram 2001-03-25 22:51 ` Bart Schaefer 0 siblings, 1 reply; 10+ messages in thread From: Zefram @ 2001-03-05 1:55 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-05 1:55 ` Zefram @ 2001-03-25 22:51 ` Bart Schaefer 2001-03-25 23:05 ` Bart Schaefer 2001-03-27 18:09 ` Zefram 0 siblings, 2 replies; 10+ messages in thread From: Bart Schaefer @ 2001-03-25 22:51 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-25 22:51 ` Bart Schaefer @ 2001-03-25 23:05 ` Bart Schaefer 2001-03-27 18:09 ` Zefram 1 sibling, 0 replies; 10+ messages in thread From: Bart Schaefer @ 2001-03-25 23:05 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-25 22:51 ` Bart Schaefer 2001-03-25 23:05 ` Bart Schaefer @ 2001-03-27 18:09 ` Zefram 2001-03-27 19:12 ` Zefram 2001-03-27 19:18 ` Bart Schaefer 1 sibling, 2 replies; 10+ messages in thread From: Zefram @ 2001-03-27 18:09 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-27 18:09 ` Zefram @ 2001-03-27 19:12 ` Zefram 2001-03-30 6:37 ` Bart Schaefer 2001-03-27 19:18 ` Bart Schaefer 1 sibling, 1 reply; 10+ messages in thread From: Zefram @ 2001-03-27 19:12 UTC (permalink / raw) To: Zefram; +Cc: Bart Schaefer, zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-27 19:12 ` Zefram @ 2001-03-30 6:37 ` Bart Schaefer 0 siblings, 0 replies; 10+ messages in thread From: Bart Schaefer @ 2001-03-30 6:37 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-27 18:09 ` Zefram 2001-03-27 19:12 ` Zefram @ 2001-03-27 19:18 ` Bart Schaefer 2001-03-27 19:25 ` Zefram 1 sibling, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2001-03-27 19:18 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-27 19:18 ` Bart Schaefer @ 2001-03-27 19:25 ` Zefram 2001-03-27 19:58 ` Bart Schaefer 0 siblings, 1 reply; 10+ messages in thread From: Zefram @ 2001-03-27 19:25 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "setopt noexec" and interactive shells 2001-03-27 19:25 ` Zefram @ 2001-03-27 19:58 ` Bart Schaefer 0 siblings, 0 replies; 10+ messages in thread From: Bart Schaefer @ 2001-03-27 19:58 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2001-03-30 6:38 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-03-04 5:20 "setopt noexec" and interactive shells Bart Schaefer 2001-03-05 1:55 ` Zefram 2001-03-25 22:51 ` Bart Schaefer 2001-03-25 23:05 ` Bart Schaefer 2001-03-27 18:09 ` Zefram 2001-03-27 19:12 ` Zefram 2001-03-30 6:37 ` Bart Schaefer 2001-03-27 19:18 ` Bart Schaefer 2001-03-27 19:25 ` Zefram 2001-03-27 19:58 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).