Re: Bug#501566: [MAN] Clarify two redirection mechanisms

[Stephane CHAZELAS <stephane.chazelas@xxxxxxxxx>]

2014-12-08 19:50:05 +0100, Stéphane Aulery:
>>>> [n1]>&n2    Redirect standard output (or fd n1) to the same "open
>>>>             file description" as on fd n2.
>>>> 
>>>> [n1]>&n2    Copy fd n2 as stdout (or fd n1)
>>>> 
>>>> [n1]>&n2    Redirect standard output (or fd n1) to the same
>>>>             resource as currently open on fd n2.

> >> "Resource" is rather unwieldy, how about simply "file"?
> >
> > "file" could be misleading
> >
> > [...]
> >
> > IMO, "resource" is vague enough so as not to give the wrong idea
> > and I like that wording because it conveys the intended
> > mechanism clearly ("redirect to same thing as"). But I agree
> > it's not ideal.
> 
> It is true that "resource" is dissonant as "file" is too restrictive. The
> term "file descriptor" is used above. Why not use it again?
[...]

If you say redirect fd n1 to fd n2, you confuse people (and I've
seen a lot of people being confused in such a way) as they
start thinking the fds become somehow linked (for instance that
in 2>&1 > file, stderr goes to stdout and then both to "file"
which is not the case). When you start thinking of "&" as
"/address/ of" (yet another improper wording) or "resource
currently open on", that clears that confusion.

If you don't like the "resource" wording, you can always got for
the "copy" one above or the POSIX wording:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05

I've seen "resource" used in the past, I've used it myself a few
times in usenet articles:

https://groups.google.com/d/msg/comp.unix.shell/48beJpLdjNE/jUak98HUekUJ
https://groups.google.com/d/msg/comp.unix.questions/EQL477tzYKk/J9ysMfqc5YIJ
https://groups.google.com/d/msg/comp.unix.aix/WcWsocnEHS0/hgSDWt19SaYJ

(see the aforementioned confusion in some of the messages that
those were replying to).

-- 
Stephane
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html