Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3E69D8A1.F493B542@phekda.freeserve.co.uk>
Date:	Sat, 08 Mar 2003 11:48:49 +0000
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT elta DOT co DOT il>
CC:	djgpp-workers AT delorie DOT com
Subject:	Re: New POSIX: pwrite [PATCH]
References:	<E18rMih-00011k-00 AT phekda DOT freeserve DOT co DOT uk> <200303071845 DOT h27Ij5d18334 AT envy DOT delorie DOT com> <3E6938EC DOT D9BFE2E4 AT phekda DOT freeserve DOT co DOT uk> <3028-Sat08Mar2003113243+0200-eliz AT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
[snip]
> Wait a minute, there's something I missed when I looked at that code:
> why do we need to disallow pwrite on redirected standard handles?
> Redirected standard handles are just normal files on DOS/Windows, so
> why should pwrite fail on them?

It seems to work OK.

> > With stdin, stdout, stderr we can assume they are pipes
> 
> You can't, really.  A redirected standard output could be a disk file,
> as in "foo > bar".  What you are thinking about is "foo | bar", but
> that doesn't have to be so, and we have no way of distinguishing
> between these two possible uses of redirection.
[snip]

So we have a choice:

(1) Always fail the write for redirected stdout, stderr, just in case it's a
pipe.

(2) Always allow the write for redirected stdout, stderr.

Even in the case "foo | bar", the handle still refers to a file, even if it is
only a temporary one. So (2) seems good and works. But will (2) result in
behaviour that is Unixy programs don't expect?

The original patch does (1). If (2) sounds good, then I'll send in another
patch.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -