Преимущества катания файлов и трубопроводов в grep

Есть ли какие-либо дополнительные преимущества в том, чтобы загружать файл и отправлять его в grep, кроме удобства? Удобство состоит в том, что, когда я получаю команды, подобные приведенным ниже, из моей истории, курсор находится в конце строки, поэтому легко изменить команду с другим текстом, чтобы выполнить поиск по одному и тому же файлу.

Итак, какие еще преимущества могут быть у следующего соглашения:

cat /var/tmp/trace.2043925204.xt | grep -in profile
cat /var/tmp/trace.2043925204.xt | grep -n Profile-Main

вместо того:

grep -in profile /var/tmp/trace.2043925204.xt 
grep -n Profile-Main /var/tmp/trace.2043925204.xt 

Лучше избегать кошек; напишите это так, если редактирование строки имеет значение:

$ < filename grep pattern

Причина в том, что передача всех данных через cat стоит памяти и ресурсов процессора. Еще одним преимуществом передачи имени файла в качестве аргумента, а не перенаправления стандартного ввода, является то, что он позволяет команде параметр mmap () файла.

Я не могу поверить , что никто не ссылается «Бесполезное Использование Cat» http://www.smallo.ruhr.de/award.html еще

Есть одно сомнительное преимущество. Если у вас длинный конвейер, он выглядит немного более ортогональным с cat:

cat file | command1 | command 2 | command3

Он объединяет все команды вместе.

Конечно, как уже говорили другие (и я делаю)

< file command1 | command2 | command3

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

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

cat file1 file2 | grep SOMETHING

будет иметь другой результат, чем

grep SOMETHING file1 file2

Который будет иметь соответствующие имена файлов в выводе. Временами я не хочу имен файлов, и это преимущество использования cat.

Там нет никакого преимущества. Ваш курсор в конце также не имеет большого значения, если вы вместо этого структурируете его так:< inputfile grep -args foo

Вам просто не нужно использовать кошку в этой ситуации вообще. Это не нужно и трата времени, потому что такие инструменты, как grep, принимают имена файлов в качестве аргументов.

[root@un1xf00 root]# time cat passwd | grep root
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin

real    0m0.021s
user    0m0.000s
sys     0m0.030s
[root@un1xf00 root]# time grep root passwd
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin

real    0m0.002s
user    0m0.000s
sys     0m0.000s
[root@un1xf00 root]#

Обновление: Спасибо, @Andy Lester, за то, что указал, что эти тайминги не принимают во внимание кеш диска. Я узнал что-то новое! Но экономия доли секунды не имеет большого значения в любом случае. Я просто думаю, что вставка кота в grep - это не логичный способ делать вещи. Это все равно, что попросить кого-то помочь вам с проблемой, когда вы вполне способны решить ее самостоятельно.

Простота редактирования - единственное реальное преимущество, и если вы делаете это в командной строке, любое дополнительное время, необходимое для запуска catи выполнения конвейера, на самом деле не будет иметь значения.

Однако нет причин делать это в скрипте оболочки.

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

Нет, и это может быть даже немного медленнее в приведенном вами примере.

pipeМежду cat и grep создается A , что не требуется при передаче имени файла непосредственно в grep. Однако я не думаю, что из-за этого вы когда-либо будете соблюдать ограничения пропускной способности.

Другие преимущества ввода данных в grep включают дополнительную предварительную обработку, такую ​​как использование утилит с более продвинутыми возможностями чтения файлов. (См tee, zcatсреди прочих).