cat file | ... vs ... <файл

Question

Есть ли случай ... или контекст, где cat file | ... ведет себя иначе, чем ... <file?

Answer 1

При чтении из обычного файла cat отвечает за чтение данных, выполняет его по своему усмотрению и может ограничить его тем, как он записывает его в конвейер. Очевидно, что содержимое сохраняется, но все остальное может быть испорчено. Например: размер блока и время поступления данных. Кроме того, труба сама по себе не всегда нейтральна: она служит в качестве дополнительного буфера между входом и ....

Быстрый и легкий способ сделать проблему размера блока кажущееся:

$ cat large-file | pv >/dev/null 
5,44GB 0:00:14 [ 393MB/s] [    <=>         ] 
$ pv <large-file >/dev/null 
5,44GB 0:00:03 [1,72GB/s] [=================================>] 100% 

Answer 2

cat file | запускает еще одну программу (кошку), которая не должна запускаться во втором случае. Это также делает его более запутанным, если вы хотите использовать «здесь документы». Но он должен вести себя одинаково.

Answer 3

cat позволит вам последовательно подключать несколько файлов. В противном случае < redirection и cat file | производят одинаковые побочные эффекты.

Answer 4

Трубы вызывают Подоболочка, который будет вызван для команды справа. Это мешает переменным среды.

cat foo | while read line 
do 
    ... 
done 
echo "$line" 

против

while read line 
do 
    ... 
done < foo 
echo "$line" 

Answer 5

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

zipinfo /dev/stdin < thezipfile.zip 

и

cat thezipfile.zip | zipinfo /dev/stdin 

Первая команда покажет содержимое ZipFile в то время как второй будет показывать ошибку, хотя это является ошибочной ошибкой, потому что zipinfo не проверяет результат вызова вызова и ошибки позже.

Answer 6

A Бесполезное использование кошки всегда следует избегать. Это как движение с ручным тормозом на. Он ничего не тратит на циклы CPU, OS постоянно переключает контекст между процессом cat и следующим в трубе. Если бы все бесполезные кошки в мире исчезли и перестали быть изобретенными, изобретенными, переданными от отца к сыну, у нас не было бы глобального потепления, потому что мы могли бы легко жить с 1,21 гигаваттами энергии, спасенной.

Спасибо. Я чувствую себя лучше. Пожалуйста, присоединяйтесь ко мне в моем крестовом походе, чтобы искоренить бесполезное использование кошки в stackoverflow. Этот сайт, насколько я понимаю, является важным вкладом в распространение бесполезных кошек. Я не обвиняю новичков, но я хочу их учить. Рабочие и новички мира, ослабьте ручные тормоза и спасите планету! 1!

Answer 7

Еще одно отличие - это поведение при блокировке open() входного файла.

Например, предполагая, что вход является FIFO без каких-либо авторов, один вызов не будет порождать дочерние программы, пока входной файл не открывается, в то время как другие будут появляться два процесса:

prog ... < a_fifo  # 'prog' not launched until shell can open file 
cat a_fifo | prog ... # 'prog' and 'cat' are running (latter may block on open) 

На практике это редко кроме замысловатых обстоятельств. prog может периодически регистрировать или выполнять некоторую работу по очистке во время ожидания ввода, например, что может случиться, даже если вход отсутствует. (Почему бы не prog быть достаточно изощренным, чтобы открыть свой собственный вход fifo без блокировки?)