Программист, да? Писать

cmd3 -p1 -p2 -p3 $(cmd2 -p4 -p5 $(cmd1))

cmd1 | cmd2 -p4 -p5 | cmd3 -p1 -p2 -p3

Как вообще это работает? Как макрос?

примерно, с небольшими ограничениями: mkfifo tmp; command >fifo & another_commаnd <fifo; rm tmp

должны соответствовать

нет, это поток: у тебя может быть данные, котоые и не влезают в оперативку: будет буфер, из которого читает вторая команда, позволяя япервой докидывать данных

Тогда, зачем это вообще нужно?

Затем что во-первых буфер командной строки не резиновый, а во-вторых пайп работает асинхронно.

Расскажи как там в Io, не стесняйся.

Потому, что если на то пошло - надо писать так:

CMD1OUT=`cmd1`
CMD2OUT=`cmd2 -p4 -p5 $CMD1OUT`
cmd3 -p1 -p2 -p3 $CMD2OUT

Что чуть более читаемо, чем твоё, но более громоздко, чем перенаправления (да и не совсем соответсвует им). Потому надо вернуть перенаправления.

з.ы. погромизд, да.

fifo

tmp в смысле

Как бы, интуитивно что-то подсказывает, что команды типа должны соответствовать

Интуиция основывается на знаниях, а у тебя их нет. Ты не различаешь такие фундаментальные понятия как аргументы и потоки ввода-вывода, а всё туда же

Не лучше ли было

Не лучше, иди учись.

Как вообще это работает? Как макрос? Эта конструкция с палкой во что-то разворачивается? Если да, то во что, в какой тип выражения? Или она является выражением языка?

«Конструкция с палкой» соединяет стандартный поток вывода одного процесса со стандартным потоком ввода другого.

а что такое потоки ввода-вывода, кстати? Кто-нибудь это вообще понимает, или все пляшут с бубнами?:) Это объекты? Вот, допустим, возьмем stdin. Его можно назвать объектом, который получает данные с клавиатуры, и отдает его на монитор(утрированно)?

интуитивно что-то подсказывает

У тебя что-то не то занимается интуицией. В любом случае, в программировании стандарт языка имеет приоритет над интуицией, я тебе это гарантирую. Так что лучше почитать документацию вместо терзания интуиции.

Тогда, зачем это вообще нужно?

Рекомендую лично ручками сравнить конструкции cat WarAndPeace.txt | sed 's/ / /g' и cat WarAndPeace.txt ; sed 's/ / /g' и на собственном примере выяснить, какая конструкция удобнее

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

Нет. Да. RTFM. Это не сахар.

Как вообще это работает?

Через файловые дескрипторы. http://www.tldp.org/LDP/abs/html/io-redirection.html

К однострочникам нет такого требования как читаемость.

Просто представь, что у тебя первая команда возвращает 10 терабайт данных.

another_command $(command)

Ню-ню.
Давай-ка вместо command подставь cat файл_пару_гигабайт

И не путай «стандартный ввод» и параметры командной строки. Ну совсем разные вещи.

command | another_commаnd

Передаёт в stdin another_command результат выполнения command.

another_command $(command)
#или
another_command `command`

а во-вторых пайп работает асинхронно

Я как это проверить? Я сейчас попробовал yes | more; echo foo. foo че-то не видать.

ради регулярности синтаксиса

Это было в пользовательском шеле, где почти всё(не только регулярности синтаксиса) проигрывает удобству массовых случаев.

90% утилит написано по принципу читают stdin пишут в stdout, ошибки в stderr. Труба нужна, чтобы стоить производьные композиции из таких утилит не заморачиваясь форматами потока.

Как бы, интуитивно что-то подсказывает, что команды типа
должны соответствовать

Нет

а что такое потоки ввода-вывода, кстати?

С точки зрения процесса, это дескрипторы через которые можно осуществлять ввод/вывод. С точки зрения ядра эти дескрипторы связаны с реальными объектами как-то файлы, сокеты, пайпы и устройства.

Вот, допустим, возьмем stdin. Его можно назвать объектом, который получает данные с клавиатуры, и отдает его на монитор(утрированно)?

Нельзя. Во-первых, он предназначен только для ввода, для вывода есть другие два стандартных потока. Во-вторых, связан он может быть с чем угодно.

Зато «y» видать. Если что, yes генерирует бесконечное количество строк с «y», а то что ты накалякал в первом посте будет пытаться вычитать их все, потом передать аргументами в принимающую команду. I/O, в отличие от, работает поточно.

Но это не соответствует понятию асинхронности, потому что инструкция yes | more ,блокирует весь поток выполнения, следующая инструкция не выполняется, она ждет своей очереди.

Так после точки с запятой идет следующая команда, она ожидает окончание предыдущей

yes | cat | cat | cat

Но это не соответствует понятию асинхронности

Почему @no-such-file назвал поточность асинхронностью у него спрашивай.

потому что инструкция yes | more ,блокирует весь поток выполнения, следующая инструкция не выполняется, она ждет своей очереди.

Ты можешь заменить ; на & и не будет.

Так после точки с запятой идет следующая команда, она ожидает окончание предыдущей

Так я и говорю, что никакой асинхронности тут нет

Товарищ «нет-такого-файла» скорее всего имел в виду, что в команде вида A | B A и B выполняются параллельно. (не совсем, но в первом приближении сойдёт)

инструкция yes | more ,блокирует весь поток

Нет. Юникс, видя, что морэ читает свой stdin с конечной скоростью замедляет yes (это объяснение для нубов). Сделай yes | grep no и ес не заблокируется, а будет работать на всю катушку.

Нет, так писать нельзя.

потому что инструкция yes | more ,блокирует весь поток выполнения

Вообще-то это 2 инструкции которые выполняются параллельно - одна пишет в поток, другая читает. И в т.ч. такие операции можно выполнять асинхронно, попутно делая что-то ещё. В любом случае foo $(bar) не обеспечивает даже параллельности. Поэтому foo|bar не эквивалентно foo $(bar) - ты не прав, тема закрыта.

Рекомендую лично ручками сравнить конструкции cat WarAndPeace.txt | sed 's/ / /g' и cat WarAndPeace.txt ; sed 's/ / /g' и на собственном примере выяснить, какая конструкция удобнее

если уж играться в «правильно-не правильно» - то твоя конструкция тоже не верна. Всякие cat | grep, cat | sed - на самом деле лучше писать так:

sed 's/ / /g' file
grep 'expression' file

И не зайобывать систему двумя процессами.

PS. Прошу прощения за некропост, в пятницу еще открыл, но меня отвлекли.

Эмм, а при чём здесь правильно/неправильно? Вопрос в различии пайпа и последовательного выполнения