From: Peter William Stephenson <pws@ifh.de>
To: zsh-workers@math.gatech.edu (Zsh hackers list)
Subject: Yet another fake subshell fix
Date: Mon, 13 Nov 1995 18:42:05 +0100 [thread overview]
Message-ID: <9511131742.AA02362@sgi.ifh.de> (raw)
More ramifications to do with exec'ing the last command in a shell
that's about to exit: going into a subshell messes up the shell
terminal file descriptor (plus other things), so that builtins are
unhappy. You can see it with things like
% zsh -fc 'vared DISPLAY'
(useless example, obviously) which I scrupulously made sure worked
when I wrote the patch to delay setting up the terminal in
non-interactive shells.
The answer is simple, correct, and I should have done it when I first
thought about exec'ing the final command: there's no point in trying
to do the fake-exec thing for a builtin or shell command anyway; it
simply removes a bit of post processing by the shell (which you might
be glad of someday).
If there are any problems with this, they must have been there for a
long time, since this is what zsh always used to do with builtins (as
well as every other command).
This would actually fix the previous problems with exit instead of
_exit in 99.99% of cases (we return to, say, getoutput, which handles
$(...), and _exit from there), but the second patch I sent for that
does get everything right so we still need it. The remaining .01% of
cases are where a nervous user asks for a real `exec read' or what
have you inside a subshell.
*** Src/exec.c~ Wed Nov 8 10:05:22 1995
--- Src/exec.c Mon Nov 13 17:58:16 1995
***************
*** 1266,1274 ****
* in a subshell pipeline, or if the shell is no longer needed *
* (e.g. the last command after a `-c'). However, if the command *
* is going into the background, or if we need to trap EXIT or *
! * ZERR, then we can't do this. */
! if (last1 && (how & Z_SYNC)
&& !sigtrapped[SIGZERR] && !sigtrapped[SIGEXIT]
&& execok()) {
cmd->flags |= CFLAG_FAKE_EXEC;
--- 1266,1276 ----
* in a subshell pipeline, or if the shell is no longer needed *
* (e.g. the last command after a `-c'). However, if the command *
* is going into the background, or if we need to trap EXIT or *
! * ZERR, then we can't do this. Also, if it's getting run in the *
! * current shell, there's no point (and we unnecessarily mess up *
! * terminal settings etc.) */
! if (last1 && (how & Z_SYNC) && !is_cursh
&& !sigtrapped[SIGZERR] && !sigtrapped[SIGEXIT]
&& execok()) {
cmd->flags |= CFLAG_FAKE_EXEC;
--
Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366
WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.
reply other threads:[~1995-11-13 18:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9511131742.AA02362@sgi.ifh.de \
--to=pws@ifh.de \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).