zsh-workers
 help / color / mirror / code / Atom feed
From: P.Stephenson@swansea.ac.uk
To: zsh-workers@math.gatech.edu (Zsh hackers list)
Subject: Re: SHTTY
Date: Thu, 06 Jul 95 11:39:22 +0100	[thread overview]
Message-ID: <19139.9507061039@pyro.swan.ac.uk> (raw)
In-Reply-To: "hoh@approve.se"'s message of "Thu, 06 Jul 95 00:38:33 +0200." <m0sTd5V-000X3YC@lorelei.approve.se>

hoh@approve.se wrote:
> Hi.
> 
> I have a problem with a change made to zsh between beta6 and beta9.
>
> If I su to another user, e.g. root su:ing to news, then the zle
> option is unset and TTY is "".
>
> The reason can be found in init.c where SHTTY is opened with this code:
> 
>     if (isatty(0))
>         SHTTY = movefd(open(ttyname(0), O_RDWR));
>     else
>         SHTTY = movefd(open("/dev/tty", O_RDWR));
> 
> There is a VERY BIG difference between the old "dup(0)" and the new
> "open(ttyname(0), O_RDWR)" if the su:ed to user don't have permission
> to open the tty. In that case SHTTY is set to -1 and then the interactive
> part of zsh just falls apart.
> 
> Why was this change made?

This was made because in the new code I/O for the TTY all goes via the
fd SHTTY's output file, shout (compare with other shells, where this
is distinct from stdout and always attached to the tty while fd 0 is).
It's not possible to guarantee that fd 0 is opened r/w.  In fact, if
you do 'exec <anyfile' within zsh it will only be opened for reading.
This means that, in the case you are having problems with, it's not
actually possible to guarantee output to the terminal at all.  (Try
'exec <$TTY' before an su to another zsh with your patch and you'll
have problems.)

The following does the best I can think of: if opening the tty r/w
fails, it dup's 0, and if that means opening the editor output fails,
it dups 1 for shout if that's a tty.  (Since about the only remaining
way of getting tty output would be stderr this is fairly general.)  To
avoid code to keep track of fileno(shout), I've set the close-on-exec
flag for that.  This all makes it a little more complex than I would
hope: but as I said, there's no guaranteed way of getting read/write
access to the tty via a single fd.

I have actually tested this and it now works even if fd 0 is read-only.

*** Src/init.c.otty	Mon Jul  3 13:34:02 1995
--- Src/init.c	Thu Jul  6 11:30:23 1995
***************
*** 328,342 ****
      setbuffer(stderr, errbuf, BUFSIZ);
  #endif
  
      if (shout) {
  	fclose(shout);
  	shout = 0;
      }
  
      /* Make sure the tty is opened read/write. */
!     if (isatty(0))
  	SHTTY = movefd(open(ttyname(0), O_RDWR));
!     else
  	SHTTY = movefd(open("/dev/tty", O_RDWR));
  
      if (SHTTY != -1) {
--- 328,346 ----
      setbuffer(stderr, errbuf, BUFSIZ);
  #endif
  
+     if (SHTTY >= 10 && (!shout || SHTTY != fileno(shout)))
+ 	close(SHTTY);
      if (shout) {
  	fclose(shout);
  	shout = 0;
      }
  
      /* Make sure the tty is opened read/write. */
!     if (isatty(0)) {
  	SHTTY = movefd(open(ttyname(0), O_RDWR));
! 	if (SHTTY == -1)
! 	    SHTTY = movefd(dup(0));
!     } else
  	SHTTY = movefd(open("/dev/tty", O_RDWR));
  
      if (SHTTY != -1) {
***************
*** 348,353 ****
--- 352,368 ----
  
  	/* Associate terminal file descriptor with a FILE pointer */
  	shout = fdopen(SHTTY, "w");
+ 	/* As a last resort, see if stdout is a tty and use that. */
+ 	if (!shout && isatty(1)) {
+ 	    int shfd = movefd(dup(1));
+ 	    if (shfd != -1) {
+ #ifdef FD_CLOEXEC
+ 		/* Don't leave this fd around in exec'd procs */
+ 		fcntl(shfd, F_SETFD, FD_CLOEXEC);
+ #endif
+ 		shout = fdopen(shfd, "w");
+ 	    }
+ 	}
  
          /* We will only use zle if shell is interactive, *
           * SHTTY != -1, and shout != 0                   */

-- 
Peter Stephenson <P.Stephenson@swansea.ac.uk>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.


      reply	other threads:[~1995-07-06 10:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-07-05 22:38 SHTTY Goran Larsson
1995-07-06 10:39 ` P.Stephenson [this message]

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=19139.9507061039@pyro.swan.ac.uk \
    --to=p.stephenson@swansea.ac.uk \
    --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).