Есть ли какие-либо дополнительные преимущества cat'ing файл и передача по каналу его к 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
Причина состоит в том, что продвижение всех данных через кошку стоит ресурсы ЦП и память. Другое преимущество передачи имени файла как аргумент, а не перенаправление stdin - то, что это позволяет команде опцию mmap () файл.
Нет никакого преимущества. Так как Ваш курсор в конце, также не имеет значения очень, если Вы структурируете его как это вместо этого: < inputfile grep -args foo
Я не могу полагать, что никто еще не сослался "На бесполезное Использование CAT" http://www.smallo.ruhr.de/award.html
Существует одно сомнительное преимущество. Если у Вас есть длинный конвейер, это выглядит более ортогональным с кошкой:
cat file | command1 | command 2 | command3
Это кластеризирует все команды вместе.
Конечно, как другие сказали (и я делаю),
< file command1 | command2 | command3
Выполняет в значительной степени то же самое. Тем не менее кошка является довольно маленькой и не снизит Ваш компьютер, если Вы используете его, когда Вы не действительно должны.
Обычно использование cat
по сравнению с прямым ударом файла ничего не изменяет, но это действительно имеет значение для определенных команд, которые заботятся, существует ли несколько файлов как аргументы, такой как grep
. Рассматриваемый вопрос:
cat file1 file2 | grep SOMETHING
будет иметь другой вывод, чем
grep SOMETHING file1 file2
Который будет иметь имена файлов соответствия в выводе. Существуют времена, я не хочу имен файлов, и это - использование преимущества cat
.
Вы просто не должны использовать кошку в этой ситуации вообще. Это является ненужным и пустая трата времени, потому что инструменты, такие как 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
и сделайте канал не будет действительно иметь значения.
Нет никакой причины сделать это в сценарии оболочки, все же.
Нет никакого преимущества вообще. Вместо того, чтобы волноваться об изменении команд, учитесь лучше перемещаться по своей командной строке оболочки с сочетаниями клавиш и ярлыками.
Нет и это могло бы даже быть поминутно медленнее в примере, который Вы даете.
A pipe
создается между кошкой и grep, который не требуется при передаче имени файла непосредственно grep. Однако я не думаю ни при каких обстоятельствах, будет Вы когда-либо наблюдать ограничения пропускной способности из-за этого.
Другие преимущества передачи по каналу входа к grep включают дополнительную предшествующую обработку, такую как использование утилит с более усовершенствованными возможностями чтения файла. (См. tee
, zcat
, среди других).