zsh-workers
 help / color / mirror / code / Atom feed
From: "Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>
To: "Sven Wischnowsky" <wischnow@informatik.hu-berlin.de>,
	<zsh-workers@sunsite.auc.dk>
Subject: RE: PATCH: Re: zpty and controlling tty (and other fd's)
Date: Thu, 4 May 2000 14:55:13 +0400	[thread overview]
Message-ID: <000701bfb5b7$39753b10$21c9ca95@mow.siemens.ru> (raw)
In-Reply-To: <200005040944.LAA30645@beta.informatik.hu-berlin.de>


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


  reply	other threads:[~2000-05-04 10:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-04  9:44 Sven Wischnowsky
2000-05-04 10:55 ` Andrej Borsenkow [this message]
2000-05-04 13:33 Sven Wischnowsky
2000-05-05 16:57 ` Andrej Borsenkow
2000-05-04 13:34 Sven Wischnowsky

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='000701bfb5b7$39753b10$21c9ca95@mow.siemens.ru' \
    --to=andrej.borsenkow@mow.siemens.ru \
    --cc=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /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).