Date: Tue, 25 Jul 2000 08:59:24 -0400 (EDT) From: Brian Dean <brdean@unx.sas.com> To: freebsd-arch@freebsd.org Subject: isatty() reports false results Message-ID: <Pine.BSF.4.21.0007250857130.51871-100000@tribble.unx.sas.com>
next in thread | raw e-mail | index | archive | help
Hi,
Recently, while setting up a VPN using pppd to establish a link across
an 'ssh' connection, I discovered that 'isatty()' will report that a
pseudo-tty is not really a tty if the slave side of the master/slave
pair has not yet been opened. This is due to the logic in
kern/tty_pty.c, ptyioctl() where all but 4 ioctl's return EAGAIN if
the slave side of the connection has not yet been opened.
The flaw in 'isatty()' is that it calls 'tcgetattr()', but only checks
for a -1 return code, and ignores the errno to determine the true
cause of the error return. My approach to fixing this is to make
'isatty()' a little smarter utilizing the following logic (WARNING -
an untested patch follows [it will be fully tested before being
committed]):
Index: isatty.c
===================================================================
RCS file: /home/ncvs/src/lib/libc/gen/isatty.c,v
retrieving revision 1.3
diff -u -r1.3 isatty.c
--- isatty.c 1998/06/09 08:32:23 1.3
+++ isatty.c 2000/07/25 02:56:04
@@ -52,7 +52,18 @@
#ifdef _THREAD_SAFE
if (_FD_LOCK(fd, FD_READ, NULL) == 0) {
#endif
- retval = (tcgetattr(fd, &t) != -1);
+ if (tcgetattr(fd, &t) == -1) {
+ /*
+ * check for pty controller open, but tty
+ * slave not yet open
+ */
+ if (errno == EAGAIN)
+ retval = 1;
+ else
+ retval = 0;
+ }
+ else
+ retval = 1;
#ifdef _THREAD_SAFE
_FD_UNLOCK(fd, FD_READ);
} else {
My question - does anyone know if this logic will break anything else,
i.e., a case where a call to 'tcgetattr()' with a descriptor that
*does not* refer to a tty will return EAGAIN? I haven't seen anything
that does so; the pseudo-tty driver seems to be unique in this regard,
so I'm thinking this change should fix 'isatty()' and not break
anything else in the process (famous last words :)).
Lastly, any suggestions for a better alternative?
Thanks,
-Brian
--
Brian Dean
bsd@FreeBSD.org
bsd@bsdhome.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007250857130.51871-100000>