[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
The following reply was made to PR standards/40554; it has been noted by GNATS.
From: "Valeriy E. Ushakov" <uwe%NetBSD.org@localhost>
Subject: Re: standards/40554
Date: Fri, 6 Feb 2009 20:05:55 +0300
On Thu, Feb 05, 2009 at 20:45:02 +0000, Robert Elz wrote:
> I assumed that he meant that the man page says (simplified)
> "duplicate stdout to n2" which kind of suggests dup2(1,n2)
> whereas what really happens is dup2(n2,1).
> I'm not sure I'd treat the "to" as an error though, as it makes the
> wording for >& match the wording for > (just as the wording for <&
> matches the wording for <).
Yeah, I guess the problem with the current wording is that it
contaminates technical details and observed effects.
We "duplicate" the descriptor, but we duplicate n2 to stdout
(i.e. dup2(n2, 1)), which has the observed effect that what goes to
stdout now goes "to n2".
I agree that keeping wording for > and >& congruent is a good thing to
do, i.e. "to" should refer to where the output ends up.
SUS says "duplicate one output file descriptor from another" but
doesn't specify which from which. Later it says that n1/stdout "will
be made to be a copy of the file descriptor denoted by word" (I don't
really like the word "copy" there - one integer value cannot really be
a "copy" of another integer value, the copying happens a level of
indirection down). SUS also doesn't explicitly say anything in that
phrase about the observed effect, presuming that the user understands
how dup2() works.
I don't know how to word it all properly *and* keep it short.
[n1]>&n2 Redirect standard output (or n1) to n2 by duplicating n2.
On Thu, Feb 05, 2009 at 21:35:02 +0000, Alan Barrett wrote:
> We could say "redirect file descriptor n1 to a duplicate of file
> descriptor n2".
That's much more confusing.
Main Index |
Thread Index |