From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Peter Stephenson <pws@ibmth.df.unipi.it>, zsh-workers@math.gatech.edu
Cc: Drazen Kacar <dave@srce.hr>
Subject: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour
Date: Fri, 29 Jan 1999 10:59:47 -0800 [thread overview]
Message-ID: <990129105947.ZM7816@candle.brasslantern.com> (raw)
In-Reply-To: <9901290916.AA53082@ibmth.df.unipi.it>
On Jan 29, 10:16am, Peter Stephenson wrote:
} Subject: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour
}
} The worst that can happen is that you get a read-only terminal,
} but the alternative is no terminal at all.
}
} I added a free for ttystrname to match the other bits. Any more
} comments?
I think the following is better; apply it on top of Peter's patch. Besides
testing fds 0 and 1 for read-write-ness before using them (when possible),
it also prefers ttyname(SHTTY) to "/dev/tty" for the setting of the $TTY
parameter.
This patch DOES NOT resolve a related bug that I reported long ago:
echo echo foo | zsh -i
gets you an interactive prompt reading from the tty, and does not echo foo.
On the other hand:
echo echo foo | zsh +Z -i
(that is, explicitly turn off zle) prints a prompt, executes "echo foo"
and then exits (end of file). I think the second behavior is the correct
one for both cases, and that it should not be necessary to use +Z.
Index: Src/init.c
===================================================================
--- init.c 1999/01/29 18:16:38 1.9
+++ init.c 1999/01/29 18:55:29
@@ -303,31 +303,45 @@
zsfree(ttystrname);
if ((ttystrname = ztrdup(ttyname(0))))
SHTTY = movefd(open(ttystrname, O_RDWR | O_NOCTTY));
+ /*
+ * xterm, rxvt and probably all terminal emulators except
+ * dtterm on Solaris 2.6 & 7 have a bug. Applications are
+ * unable to open /dev/tty or /dev/pts/<terminal number here>
+ * because something in Sun's STREAMS modules doesn't like
+ * it. The open() call fails with EBUSY which is not even
+ * listed as a possibility in the open(2) man page. So we'll
+ * try to outsmart The Company. -- <dave@srce.hr>
+ *
+ * Presumably there's no harm trying this on any OS, given that
+ * isatty(0) worked but opening the tty didn't. Possibly we won't
+ * get the tty read/write, but it's the best we can do -- pws
+ *
+ * Try both stdin and stdout before trying /dev/tty. -- Bart
+ */
+#if defined(HAVE_FCNTL_H) && defined(F_GETFL)
+#define rdwrtty(fd) ((fcntl(fd, F_GETFL) & O_RDWR) == O_RDWR)
+#else
+#define rdwrtty(fd) 1
+#endif
+ if (SHTTY == -1 && rdwrtty(0)) {
+ SHTTY = movefd(dup(0));
+ }
}
- if (SHTTY == -1 &&
- (SHTTY = movefd(open("/dev/tty", O_RDWR | O_NOCTTY))) != -1) {
+ if (SHTTY == -1 && isatty(1) && rdwrtty(1) &&
+ (SHTTY = movefd(dup(1))) != -1) {
zsfree(ttystrname);
- ttystrname = ztrdup("/dev/tty");
+ ttystrname = ztrdup(ttyname(1));
}
- /*
- * xterm, rxvt and probably all terminal emulators except dtterm on
- * Solaris 2.6 & 7 have a bug. Applications are unable to open /dev/tty
- * or /dev/pts/<terminal number here> because something in Sun's STREAMS
- * modules doesn't like it. The open() call fails with EBUSY which
- * is not even listed as a possibility in the open(2) man page.
- * So we'll try to outsmart The Company. -- <dave@srce.hr>
- *
- * Presumably there's no harm trying this on any OS, given that
- * isatty(0) worked but opening the tty didn't. Possibly we won't
- * get the tty read/write, but it's the best we can do -- pws
- */
- if (SHTTY == -1 && isatty(0) && (SHTTY = movefd(dup(0))) != -1) {
+ if (SHTTY == -1 &&
+ (SHTTY = movefd(open("/dev/tty", O_RDWR | O_NOCTTY))) != -1) {
zsfree(ttystrname);
- ttystrname = ztrdup(ttyname(0));
+ ttystrname = ztrdup(ttyname(SHTTY));
}
if (SHTTY == -1) {
zsfree(ttystrname);
ttystrname = ztrdup("");
+ } else if (!ttystrname) {
+ ttystrname = ztrdup("/dev/tty");
}
/* We will only use zle if shell is interactive, *
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1999-01-29 18:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-27 22:26 Drazen Kacar
1999-01-28 5:46 ` Bart Schaefer
1999-01-28 9:38 ` Drazen Kacar
1999-01-29 3:47 ` Drazen Kacar
1999-01-29 9:16 ` PATCH: 3.1.5* & 3.0.5: " Peter Stephenson
1999-01-29 18:59 ` Bart Schaefer [this message]
1999-01-29 19:08 ` PATCH: (more) " Bart Schaefer
1999-01-30 5:54 ` Drazen Kacar
1999-01-30 12:43 ` Peter Stephenson
1999-01-30 12:51 ` Peter Stephenson
1999-01-30 18:04 ` Bart Schaefer
1999-01-30 18:27 ` Drazen Kacar
1999-01-30 20:41 ` Terminal initialization and (non-)interactive shells Bart Schaefer
1999-02-01 0:50 ` Drazen Kacar
1999-02-01 1:24 ` Bart Schaefer
1999-02-03 11:08 ` PATCH: 3.1.5-pws-6: ttys revisited Peter Stephenson
1999-01-30 13:29 ` PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour Drazen Kacar
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=990129105947.ZM7816@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=dave@srce.hr \
--cc=pws@ibmth.df.unipi.it \
--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).