почему трубы используются вместо перенаправления ввода

Question 1

Я новичок в системах Linux и не могу понять, почему нам нужны два оператора, которые могут перенаправлять вывод: pipe как | и оператор перенаправления вывода >? Разве мы не можем всегда использовать второе? В большинстве случаев я вижу, что канал используется, если несколько команд связаны друг с другом. Однако, если выход перенаправляется в файл, как в echo 'hello' > filename, используется оператор перенаправления вывода. Что мне здесь не хватает?

Question 2

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

В видео Конвейер Unix , создатель awk язык и один из исходных людей, которые работали над AT& T Unix Brian Kernighan объясняет:

Первый, Вы не должны писать одну большую крупную программу - у Вас есть существующие меньшие программы, которые могут уже внести свой вклад задания... Другой - это, возможно, что объем данных, который Вы обрабатываете, не соответствовал бы при хранении его в файле..., потому что помнят, мы вернулись в дни, когда диски на этих вещах имели, если Вы были удачливы, Мегабайт или два из данных... Таким образом, конвейер никогда не должен был инстанцировать целого вывода

, Как Вы видите в контексте, который были созданы конвейеры, они на самом деле не были просто коммуникационным устройством, но также и сохраняют пространство памяти и упрощают разработку. Несомненно, мы можем использовать вывод/перенаправление ввода для всего (особенно в наше время с емкостью хранения, находящейся в диапазоне Терабайт), однако который был бы неэффективен с точки зрения устройства хранения данных, и также скорость обработки - помнит прямое питание вывода от одной команды до другого с |. Рассмотрите что-то как command1 | grep 'something'. Если Вы запишете вывод command1 сначала в файл, то он займет время для записи всего, то позволенный grep проходят целый файл. С конвейером и тем, что вывод буферизуется (подразумевать, что паузы процесса левой стороны перед процессом правой стороны готовы читать снова), вывод идет непосредственно от одной команды до другого, экономя время.

Это стоит отметить, что для межпроцессного взаимодействия, существует вариант использования именованные каналы , для которого можно использовать > оператор для записи из одной команды, и < для разрешения другой команде, считанной из него, и это - вариант использования, где Вы действительно хотите иметь конкретное место назначения в файловой системе, где несколько сценариев/команд могут записать в и договориться о том конкретном месте назначения. Но то, когда это - ненужный, неименованный канал |, является всем, в чем Вы действительно нуждаетесь.

Question 3

Question 4

| используются для отправки вывода одной команды, как введено к другой команде, которая происходит затем после символа вертикальной черты.
```
$ echo foo | grep -o 'f'
f
```
Для перенаправления вывода одной команды в файл можно использовать перенаправление вывода > оператор.
```
$ echo foo > file1
```
Это пишет foo в file1. Вы не должны вручную создавать тот файл.
, Если Вы хотите перенаправить вывод во многие файлы тогда, необходимо использовать tee команда.
```
echo foo | tee file1 file2
```
Это пишет foo в file1 и file2. Вы не должны вручную создавать это файлы. Теперь file1 и file2 содержат только строку foo.

Question 5

Я верю <> операторы используются для чтения/записи файлов, тогда как | символ используется для передачи по каналу stdout одной команды другому.

cal | less

позволяет Вам просмотреть вывод cal в команде, названной меньше.

cal > less

помещает вывод cal в файл, названный меньше.

Question 6

Существует большой разговор о перенаправлении вывода, но я думал, что этот вопрос был о входе. Я собираюсь проигнорировать > и >>, потому что они не имеют никакого отношения к входу. Вместо этого я собираюсь сфокусироваться на <, <(...) и |:

< ожидает читать из файла в STDIN, в то время как,
<(...) предоставляет дескриптор файла STDOUT из команды (... здесь)
|, каналы STDOUT от одного процесса в STDIN из следующих

Так эти < не непосредственно эквивалентны каналу (это читает из файла), и эти <(...) читает из правильного места, но это дает дескриптор файла как вывод. Необходимо объединить их для предложения эквивалента каналу.

a | b
< <(a) b

Просто чтение, что, я надеюсь, что полный объясняет, почему канал существует. Это намного более читаемо.

Sergiy Kolodyazhnyy · Accepted Answer · 7 October 2019 в 05:01

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

В видео Конвейер Unix , создатель awk язык и один из исходных людей, которые работали над AT& T Unix Brian Kernighan объясняет:

Первый, Вы не должны писать одну большую крупную программу - у Вас есть существующие меньшие программы, которые могут уже внести свой вклад задания... Другой - это, возможно, что объем данных, который Вы обрабатываете, не соответствовал бы при хранении его в файле..., потому что помнят, мы вернулись в дни, когда диски на этих вещах имели, если Вы были удачливы, Мегабайт или два из данных... Таким образом, конвейер никогда не должен был инстанцировать целого вывода

, Как Вы видите в контексте, который были созданы конвейеры, они на самом деле не были просто коммуникационным устройством, но также и сохраняют пространство памяти и упрощают разработку. Несомненно, мы можем использовать вывод/перенаправление ввода для всего (особенно в наше время с емкостью хранения, находящейся в диапазоне Терабайт), однако который был бы неэффективен с точки зрения устройства хранения данных, и также скорость обработки - помнит прямое питание вывода от одной команды до другого с |. Рассмотрите что-то как command1 | grep 'something'. Если Вы запишете вывод command1 сначала в файл, то он займет время для записи всего, то позволенный grep проходят целый файл. С конвейером и тем, что вывод буферизуется (подразумевать, что паузы процесса левой стороны перед процессом правой стороны готовы читать снова), вывод идет непосредственно от одной команды до другого, экономя время.

Это стоит отметить, что для межпроцессного взаимодействия, существует вариант использования именованные каналы , для которого можно использовать > оператор для записи из одной команды, и < для разрешения другой команде, считанной из него, и это - вариант использования, где Вы действительно хотите иметь конкретное место назначения в файловой системе, где несколько сценариев/команд могут записать в и договориться о том конкретном месте назначения. Но то, когда это - ненужный, неименованный канал |, является всем, в чем Вы действительно нуждаетесь.

Avinash Raj · Answer 2 · 26 June 2014 в 14:33

| используются для отправки вывода одной команды, как введено к другой команде, которая происходит затем после символа вертикальной черты.
```
$ echo foo | grep -o 'f'
f
```
Для перенаправления вывода одной команды в файл можно использовать перенаправление вывода > оператор.
```
$ echo foo > file1
```
Это пишет foo в file1. Вы не должны вручную создавать тот файл.
, Если Вы хотите перенаправить вывод во многие файлы тогда, необходимо использовать tee команда.
```
echo foo | tee file1 file2
```
Это пишет foo в file1 и file2. Вы не должны вручную создавать это файлы. Теперь file1 и file2 содержат только строку foo.

John Hunt · Answer 3 · 26 June 2014 в 14:33

Я верю <> операторы используются для чтения/записи файлов, тогда как | символ используется для передачи по каналу stdout одной команды другому.

cal | less

позволяет Вам просмотреть вывод cal в команде, названной меньше.

cal > less

помещает вывод cal в файл, названный меньше.

Oli · Answer 4 · 26 June 2014 в 14:33

Существует большой разговор о перенаправлении вывода, но я думал, что этот вопрос был о входе. Я собираюсь проигнорировать > и >>, потому что они не имеют никакого отношения к входу. Вместо этого я собираюсь сфокусироваться на <, <(...) и |:

< ожидает читать из файла в STDIN, в то время как,
<(...) предоставляет дескриптор файла STDOUT из команды (... здесь)
|, каналы STDOUT от одного процесса в STDIN из следующих

Так эти < не непосредственно эквивалентны каналу (это читает из файла), и эти <(...) читает из правильного места, но это дает дескриптор файла как вывод. Необходимо объединить их для предложения эквивалента каналу.

a | b
< <(a) b

Просто чтение, что, я надеюсь, что полный объясняет, почему канал существует. Это намного более читаемо.

почему трубы используются вместо перенаправления ввода

4 ответа

Другие вопросы по тегам:

Похожие вопросы: