Первая ссылка в гугле http://stackoverflow.com/questions/818255/in-the-shell-what-is-21

мы направляем stderr в stdout. Всё, что программа пишет в stderr, попадает туда, куда направлен stdout.

это не ответ, вот, например ещё вопросы:

& is shell syntax for «fold a file descriptor into another»

что такое операция «fold» - это черезстрочное перемешивание или append?
а как оно будет работать, если stdout синхронизирован с stdin ?

Где лежит официальная документация про оператор >&

Почему >& парсится слитно, а не как два разных оператора > и &

Indaril_Shpritz

В базе пользователей ЛОРа, что означает такая запись?

Не, ну в самом деле. Ты зарегистрировался примерно через 13 минут после шутки про Индарила Шприца, возникшей в топике про генератор никнеймов для RPG ("...и чтобы, например, имена для медиков намекали на медицинские термины"). Значит, ты активно сидел на ЛОРе. С другой стороны, качеством твои вопросов народ как-то не восхищается. Значит, ты какой-то начинающий ололо пользователь.

Может, ты есть тёмная сторона моей личности?

P.S.А куда делось преобразование кавычек?

а что может являться точками назначения для потоков? Куда их можно направлять в принципе?

Что значит «попадает» - побитно перемешивается или побайтно?

http://www.tldp.org/LDP/abs/html/io-redirection.html

да, это объясняет всё, кроме режима перемешивания.

Как можно направить два потока в один файл, разве файл при этом не оказывается заблокирован на запись другими потоками при направлении туда первого из потоков?

Как это работает в многопоточных программах? Или получается, что пока одна нить записывает, все остальные нити стоят её ждут?

Ты же в курсе что такое файловый дескриптор, правда?

не очень. Прочитал:
http://ru.wikipedia.org/wiki/Файловый_дескриптор

А на что ты намекаешь?

я даже уточню вопросы:
когда мы передаём дескриптор из одного потока в другой поток - надо ли создавать клон этого дескриптора при помощи специальной функции операционной системы?
как всё-таки работает «направление» дескриптора в файл. Это такая таблица внутри ОС, состоящая из пар <файловый дескриптор, inode-файла> ?

примерно через 13 минут после шутки про Индарила Шприца

Так вот откуда это!

В твоих уточненных вопросах настолько все перемешано, что возникает подозрение - IRL ты вовсе не пони.
Если действительно интересно до уровня «специальных вызовов операционной системы», можешь почитать 11, 12 и 13 вот тут

Через shell - в файлы, другие потоки или через pipe направлять в качестве входа в другую программу.

как всё-таки работает «направление» дескриптора в файл. Это такая таблица внутри ОС, состоящая из пар <файловый дескриптор, inode-файла> ?

На уровне shell-а - при выполнении команды prog > file shell делает fork, в потомке открывает file на запись, делает dup2(fid, 1), в этот момент stdout уже перенаправлен в file ну и после этого делает exec в prog. Тут начинает выполняться prog, но дескрипторы у него перенаправлены куда положено.

На уровне ядра ОС - я так понимаю, есть некая абстракция VFS, с каждым descriptor-ом связан некий абстрактный полиморфный класс и при вызове write вызывается соответствующий метод в наследнике этого класса, а что там будет - вывод в терминал, реальный файл, псевдофайл, сокет - уже зависит от этого наследника. Т.е. там таблица из пар <дескриптор, absract_device>. Но здесь могу фигню говорить, никогда не читал код линукса.

настолько все перемешано

если бы мне было понятно, я бы не спрашивал

можешь почитать 11, 12 и 13

прочитал 11.1, 11.1.1, 12.5, 12.11, 13.4, 13.5, 13.12, 13.15
перечитал свои вопросы. Ничего не поменялось.
мне непонятно, что такое «Channels», которые где-то в недрах создаются

Епсти. В ядре есть структура за файл (устройство), к ней ведет дескриптор. Два дескриптора могут вести к одному файлу, имея попутно свои off_t и пр. Программно это dup(2). Никаких явных блокировок там нет, кроме разве что в момент самих вызовов write, которые просто как-то сериализуются в очень низком уровне.

https://www.google.ru/search?q=unix file descriptor&tbm=isch

Тебе надо хорошую книжку по юниксу почитать, т.к. это очень глупый вопрос и почти бессмысленно на него отвечать.