* PATCH: Re: zpty and controlling tty (and other fd's)
@ 2000-05-04 9:44 Sven Wischnowsky
2000-05-04 10:55 ` Andrej Borsenkow
0 siblings, 1 reply; 5+ messages in thread
From: Sven Wischnowsky @ 2000-05-04 9:44 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> Should not we reset controlling tty for external command as well? Else,
> I'm afraid, commands that directly open /dev/tty may have problems with
> it.
Hm, quite reasonable. This tries it, tested on Digital Unix and
Linux. I have no BSDish system around, could someone test it there?
On True64 Unix O_NOCTTY is implicit and cannot be unset. How weird.
> ...
>
> Oh, yes, and why nslookup has fd's 10 and 11 open at all?
Missing close()s? (The parent shell's stdio descriptors.)
There is also a hunk that tries to avoid closing the connection to the
child too early (when there is still something to read).
Bye
Sven
Index: Src/Modules/zpty.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zpty.c,v
retrieving revision 1.3
diff -u -r1.3 zpty.c
--- Src/Modules/zpty.c 2000/04/07 15:01:03 1.3
+++ Src/Modules/zpty.c 2000/05/04 09:42:34
@@ -155,33 +155,29 @@
/**** maybe we should use configure here */
/**** and we certainly need more/better #if tests */
-#ifdef __osf__
-
-static int
-get_pty(int *master, int *slave)
-{
- return openpty(master, slave, NULL, NULL, NULL);
-}
-
-#else /* ! __osf__ */
-
#if defined(__SVR4) || defined(sinix)
#include <sys/stropts.h>
static int
-get_pty(int *master, int *slave)
+get_pty(int master, int *retfd)
{
- int mfd, sfd;
- char *name;
+ static char *name;
+ static int mfd, sfd;
+
int ret;
- if ((mfd = open("/dev/ptmx", O_RDWR)) < 0)
- return 1;
+ if (master) {
+ if ((mfd = open("/dev/ptmx", O_RDWR)) < 0)
+ return 1;
- if (grantpt(mfd) || unlockpt(mfd) || !(name = ptsname(mfd))) {
- close(mfd);
- return 1;
+ if (grantpt(mfd) || unlockpt(mfd) || !(name = ptsname(mfd))) {
+ close(mfd);
+ return 1;
+ }
+ *retfd = mfd;
+
+ return 0;
}
if ((sfd = open(name, O_RDWR)) < 0) {
close(mfd);
@@ -205,16 +201,16 @@
close(sfd);
return 1;
}
- *master = mfd;
- *slave = sfd;
+ *retfd = sfd;
+
return 0;
}
#else /* ! (defined(__SVR4) || defined(sinix)) */
static int
-get_pty(int *master, int *slave)
+get_pty(int master, int *retfd)
{
#ifdef __linux
@@ -224,34 +220,38 @@
static char char1[] = "pq";
static char char2[] = "0123456789abcdef";
#endif /* __linux */
-
- char name[11], *p1, *p2;
- int mfd, sfd;
- strcpy(name, "/dev/ptyxx");
+ static char name[11];
+ static int mfd, sfd;
+ char *p1, *p2;
+
+ if (master) {
+ strcpy(name, "/dev/ptyxx");
+
+ for (p1 = char1; *p1; p1++) {
+ name[8] = *p1;
+ for (p2 = char2; *p2; p2++) {
+ name[9] = *p2;
+ if ((mfd = open(name, O_RDWR)) >= 0) {
+ *retfd = mfd;
- for (p1 = char1; *p1; p1++) {
- name[8] = *p1;
- for (p2 = char2; *p2; p2++) {
- name[9] = *p2;
- if ((mfd = open(name, O_RDWR)) >= 0) {
- name[5] = 't';
- if ((sfd = open(name, O_RDWR)) >= 0) {
- *master = mfd;
- *slave = sfd;
-
return 0;
}
- name[5] = 'p';
- close(mfd);
}
}
}
+ name[5] = 't';
+ if ((sfd = open(name, O_RDWR)) >= 0) {
+ *retfd = sfd;
+
+ return 0;
+ }
+ close(mfd);
+
return 1;
}
#endif /* __SVR4 */
-#endif /* __osf__ */
static int
newptycmd(char *nam, char *pname, char **args, int echo, int block)
@@ -264,7 +264,7 @@
zwarnnam(nam, "unknown command: %s", *args, 0);
return 1;
}
- if (get_pty(&master, &slave)) {
+ if (get_pty(1, &master)) {
zwarnnam(nam, "can't open pseudo terminal", NULL, 0);
return 1;
}
@@ -274,6 +274,42 @@
zwarnnam(nam, "couldn't create pty command: %s", pname, 0);
return 1;
} else if (!pid) {
+
+ pid = getpid();
+
+#ifdef HAVE_SETSID
+ setsid();
+#else
+#ifdef TIOCNOTTY
+ {
+ int t = open("/dev/tty", O_RDWR);
+
+ ioctl(t, TIOCNOTTY, 0);
+ close(t);
+ }
+#endif
+#endif
+
+ if (get_pty(0, &slave))
+ exit(1);
+
+#ifdef TIOCSCTTY
+ ioctl(slave, TIOCSCTTY, 0);
+#endif
+
+ /* This is taken from attachtty(). Should we exit in case of
+ * failure? */
+
+#ifdef HAVE_TCSETPGRP
+ tcsetpgrp(slave, pid);
+#else
+# if ardent
+ setpgrp();
+# else
+ ioctl(slave, TIOCSPGRP, &pid);
+# endif
+#endif
+
if (!echo) {
struct ttyinfo info;
@@ -317,13 +353,13 @@
close(slave);
- setpgrp(0L, getpid());
+ if (SHTTY != -1)
+ close(SHTTY);
execve(cmd, args, environ);
exit(0);
}
master = movefd(master);
- close(slave);
p = (Ptycmd) zalloc(sizeof(*p));
@@ -539,7 +575,6 @@
zwarnnam(nam, "no such pty command: %s", *args, 0);
return 1;
}
- checkptycmd(p);
if (p->fin)
return 1;
return (ops['r'] ?
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: PATCH: Re: zpty and controlling tty (and other fd's)
2000-05-04 9:44 PATCH: Re: zpty and controlling tty (and other fd's) Sven Wischnowsky
@ 2000-05-04 10:55 ` Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 2000-05-04 10:55 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
>
> On True64 Unix O_NOCTTY is implicit and cannot be unset. How weird.
>
Hmm ... if I correctly recall, first tty opened by process becomes
controlling tty. It means, that if child has closed all of it's file
descriptors and reopens tty for stdin (duplicating it for stdout,
stderr) - it gets it as controlling tty. It should be fairly portable.
And closing all descriptors is probably needed anyway because ...
> >
> > Oh, yes, and why nslookup has fd's 10 and 11 open at all?
>
> Missing close()s? (The parent shell's stdio descriptors.)
>
... there is more that remains from parent:
bor@itsrm2% lsof -c nslookup
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nslookup 15216 bor cwd VDIR 4,5 3072 125 /home/bor
nslookup 15216 bor txt VREG 4,3 69961 46376 /usr/sbin/nslookup
nslookup 15216 bor txt VREG 4,3 715161 23840 /usr/lib/libc.so.1
nslookup 15216 bor txt VREG 4,3 320397 23882
/usr/lib/libresolv.so
nslookup 15216 bor txt VREG 4,3 192333 23859
/usr/lib/libsocket.so
nslookup 15216 bor txt VREG 4,3 592617 26181 /usr/lib/libnsl.so
nslookup 15216 bor 0u VCHR 112,10 0t66 4204
STR:/dev/pts/10->pts
nslookup 15216 bor 1u VCHR 112,10 0t66 4204
STR:/dev/pts/10->pts
nslookup 15216 bor 2u VCHR 112,10 0t66 4204
STR:/dev/pts/10->pts
nslookup 15216 bor 3u VCHR 111,10 0t69 STR:/dev/ptmx->ptm
nslookup 15216 bor 13r VREG 4,5 1303776 24152
/home/bor/.zsh.d/std-3.1.7-pre-2.zwc
Note fd's 3 and 13. 3 is master side of pty (child does not need it,
does it?) And 13 is left over from wordcode file mapping. Mapping itself
goes away after exec (at least here - I expect, it should be true for
all Unices) - but we have to close fd anyway.
-andrej
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: PATCH: Re: zpty and controlling tty (and other fd's)
2000-05-04 13:33 Sven Wischnowsky
@ 2000-05-05 16:57 ` Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 2000-05-05 16:57 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
> >
> > Note fd's 3 and 13. 3 is master side of pty (child does not need it,
> > does it?)
>
> Of course I tried to close it -- and on Linux this messed up the
> parent's (i.e. the shell's) terminal settings. Don't know how this
> came.
>
Well, at least Midnight and Screen do it - so, it is possible. This one
is from Midnight code that spawns subshell. I do not know, how usefulr
it is.
/* {{{ Open the slave side of the pty: again */
pty_slave = pty_open_slave (pty_name);
/* This must be done before closing the master side of the pty,
*/
/* or it will fail on certain idiotic systems, such as Solaris.
*/
/* Close master side of pty. This is important; apart from
*/
/* freeing up the descriptor for use in the subshell, it also
*/
/* means that when MC exits, the subshell will get a SIGHUP and
*/
/* exit too, because there will be no more descriptors pointing
*/
/* at the master side of the pty and so it will disappear.
*/
close (subshell_pty);
I do not use Linux, but until this is cleared there - porbably under
#ifndef __LINUX (or whatever)?
-andrej
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: PATCH: Re: zpty and controlling tty (and other fd's)
@ 2000-05-04 13:34 Sven Wischnowsky
0 siblings, 0 replies; 5+ messages in thread
From: Sven Wischnowsky @ 2000-05-04 13:34 UTC (permalink / raw)
To: zsh-workers
Ahem.
Bye
Sven
Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.6
diff -u -r1.6 exec.c
--- Src/exec.c 2000/05/02 13:08:19 1.6
+++ Src/exec.c 2000/05/04 13:30:01
@@ -356,6 +356,7 @@
if (!*eep)
eep[1] = NULL;
*eep = buf;
+ closedumps();
execve(pth, argv, environ);
/* If the execve returns (which in general shouldn't happen), *
Index: Src/parse.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/parse.c,v
retrieving revision 1.6
diff -u -r1.6 parse.c
--- Src/parse.c 2000/04/12 13:06:18 1.6
+++ Src/parse.c 2000/05/04 13:30:03
@@ -3030,6 +3030,16 @@
}
}
+/**/
+mod_export void
+closedumps(void)
+{
+ FuncDump p;
+
+ for (p = dumps; p; p = p->next)
+ zclose(p->fd);
+}
+
#else
void
@@ -3042,6 +3052,11 @@
{
}
+void
+closedumps(void)
+{
+}
+
#endif
/**/
@@ -3070,3 +3085,4 @@
}
return ret;
}
+
Index: Src/Modules/zpty.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zpty.c,v
retrieving revision 1.4
diff -u -r1.4 zpty.c
--- Src/Modules/zpty.c 2000/05/04 09:53:42 1.4
+++ Src/Modules/zpty.c 2000/05/04 13:30:03
@@ -356,6 +356,8 @@
if (SHTTY != -1)
close(SHTTY);
+ closedumps();
+
execve(cmd, args, environ);
exit(0);
}
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: PATCH: Re: zpty and controlling tty (and other fd's)
@ 2000-05-04 13:33 Sven Wischnowsky
2000-05-05 16:57 ` Andrej Borsenkow
0 siblings, 1 reply; 5+ messages in thread
From: Sven Wischnowsky @ 2000-05-04 13:33 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> > On True64 Unix O_NOCTTY is implicit and cannot be unset. How weird.
>
> Hmm ... if I correctly recall, first tty opened by process becomes
> controlling tty. It means, that if child has closed all of it's file
> descriptors and reopens tty for stdin (duplicating it for stdout,
> stderr) - it gets it as controlling tty. It should be fairly portable.
What I said with the above is that on True64 Unix opening a terminal
in a process with no controlling tty does *not* make that terminal the
controlling tty of the process.
So: `how weird'.
> ...
>
> Note fd's 3 and 13. 3 is master side of pty (child does not need it,
> does it?)
Of course I tried to close it -- and on Linux this messed up the
parent's (i.e. the shell's) terminal settings. Don't know how this
came.
> And 13 is left over from wordcode file mapping. Mapping itself
> goes away after exec (at least here - I expect, it should be true for
> all Unices) - but we have to close fd anyway.
Ah, right. I don't use wordcode files in development versions.
This adds the closedumps() function and makes it be called in zpty.c
and zexecve(). Does anyone know of other places where it should be
called?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-05-05 16:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-04 9:44 PATCH: Re: zpty and controlling tty (and other fd's) Sven Wischnowsky
2000-05-04 10:55 ` Andrej Borsenkow
2000-05-04 13:33 Sven Wischnowsky
2000-05-05 16:57 ` Andrej Borsenkow
2000-05-04 13:34 Sven Wischnowsky
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).