zsh-workers
 help / color / mirror / code / Atom feed
* RE: PATCH: Re: zpty and controlling tty (and other fd's)
@ 2000-05-04 13:33 Sven Wischnowsky
  2000-05-04 13:48 ` nslookup (function) problem Andrej Borsenkow
  2000-05-05 16:57 ` PATCH: Re: zpty and controlling tty (and other fd's) Andrej Borsenkow
  0 siblings, 2 replies; 6+ 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] 6+ messages in thread

* nslookup (function) problem
  2000-05-04 13:33 PATCH: Re: zpty and controlling tty (and other fd's) Sven Wischnowsky
@ 2000-05-04 13:48 ` Andrej Borsenkow
  2000-05-05 16:57 ` PATCH: Re: zpty and controlling tty (and other fd's) Andrej Borsenkow
  1 sibling, 0 replies; 6+ messages in thread
From: Andrej Borsenkow @ 2000-05-04 13:48 UTC (permalink / raw)
  To: zsh-workers

With the latest Zsh (and no special settings apart PAGER=less):

bor@itsrm2% command nslookup
Default Server:  mowd017a.mow.siemens.ru
Address:  139.24.18.1

> ?
# @(#)nslookup.help     Revision: 3.1   92/09/23 13:57:57
#
# @(#)nslookup.help     Revision: 2.2   91/06/06 17:41:55
#
Commands:       (identifiers are shown in uppercase, [] means optional)
NAME            - print info about the host/domain NAME using default
server
NAME1 NAME2     - as above, but use NAME2 as server
help or ?       - print info on common commands; see nslookup(1) for
details
set OPTION      - set an option
    all         - print options, current server and host
    [no]debug   - print debugging information
    [no]d2      - print exhaustive debugging information
    [no]defname - append domain name to each query
    [no]recurse - ask for recursive answer to query
    [no]vc      - always use a virtual circuit
    domain=NAME - set default domain name to NAME
    srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2,
etc.
    root=NAME   - set root server to NAME
    retry=X     - set number of retries to X
    timeout=X   - set initial time-out interval to X seconds
    querytype=X - set query type, e.g.,
A,ANY,CNAME,HINFO,MX,NS,PTR,SOA,WKS
    type=X      - synonym for querytype
    class=X     - set query class to one of IN (Internet), CHAOS, HESIOD
or ANY
/usr/lib/named/nslookup.help 62%
....

that is , it runs help output through pager (`less' in my case).

Unfortunately, function nslookup hangs completely in this case:

bor@itsrm2% autoload -U nslookup
bor@itsrm2% nslookup
Default Server:  mowd017a.mow.siemens.ru
Address:  139.24.18.1

> ?
nothing comes here; it habgs; it is no more possible to kill it with ^C,
^\ or ^Z.

-andrej


^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: PATCH: Re: zpty and controlling tty (and other fd's)
  2000-05-04 13:33 PATCH: Re: zpty and controlling tty (and other fd's) Sven Wischnowsky
  2000-05-04 13:48 ` nslookup (function) problem Andrej Borsenkow
@ 2000-05-05 16:57 ` Andrej Borsenkow
  1 sibling, 0 replies; 6+ 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] 6+ 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; 6+ 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] 6+ messages in thread

* RE: 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, 0 replies; 6+ 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] 6+ messages in thread

* 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; 6+ 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] 6+ messages in thread

end of thread, other threads:[~2000-05-05 16:58 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-04 13:33 PATCH: Re: zpty and controlling tty (and other fd's) Sven Wischnowsky
2000-05-04 13:48 ` nslookup (function) problem Andrej Borsenkow
2000-05-05 16:57 ` PATCH: Re: zpty and controlling tty (and other fd's) Andrej Borsenkow
  -- strict thread matches above, loose matches on Subject: below --
2000-05-04 13:34 Sven Wischnowsky
2000-05-04  9:44 Sven Wischnowsky
2000-05-04 10:55 ` Andrej Borsenkow

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).