From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5902bcf4c776111c8c09f50a06e1c8ea@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 22 Jun 2008 07:47:43 -0400
In-Reply-To: <ba0d3bc70806220045x312ad75bo4714767ebcba9ba9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] 'stuck' windows.
Topicbox-Message-UUID: c50e6a18-ead3-11e9-9d60-3106f5b1d025

> On 6/22/08, Russ Cox <rsc@swtch.com> wrote:
>> It is not waiting for dossrv to exit,
>> so much as it is waiting for all the open
>> file descriptors referring to that window's
>> /dev/cons to be closed.  Dossrv just happens
>> to be the one holding them.
>>
>> Probably the various dossrv'ing scripts should run
>>
>> 	dossrv </dev/null >/dev/null >[2=1]
>
> But that's what 9fat: does (well, not literally, since it does 'dossrv
>>/dev/null </dev/null >[2]/dev/null', but it means the same). So then
> dossrv shouldn't be holding the window's /dev/cons open, right?

russ is should be correct.

i think that dossrv's quirks are surprising.  the
redirection in 9fat: is superfluous since 9fat opens
/dev/null on fds 0 and 1 and it makes this surprise
move for fd 2:

	if(!chatty){
		close(2);
		open("#c/cons", OWRITE);
	}

that's downright antisocial.  maybe there's a good
reason.  but i can't think of one now.

- erik