NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: standards/40554

The following reply was made to PR standards/40554; it has been noted by GNATS.

From: "Valeriy E. Ushakov" <>
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.

Home | Main Index | Thread Index | Old Index