Разделы fdisk не отображаются с помощью lsblk

tl;dr:Оболочки не делают этого автоматически, потому что затраты превышают вероятные выгоды.

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

1. Реализовать catкак встроенную функцию, сохранив различие между файлом и каналом. Это сэкономит затраты на exec и, возможно, на форк.
2. Выполните полный анализ конвейера, зная различные команды, используемые, чтобы увидеть, имеет ли значение файл/канал, а затем действуйте на основе этого.

Затем вы должны рассмотреть затраты и преимущества каждого подхода. Преимущества достаточно просты:

1. В любом случае избегайте exec (изcat)
2. Во втором случае, когда возможна перенаправленная замена, избегание форка.
3. В тех случаях, когда вам приходится использовать конвейер, может быть иногда возможно избежать fork/vfork, но часто нет. Это связано с тем, что эквивалент cat -должен запускаться одновременно с остальной частью конвейера.

Таким образом, вы сэкономите немного процессорного времени и памяти, особенно если сможете избежать форка. Конечно, вы экономите это время и память только тогда, когда функция действительно используется. И вы действительно экономите только время fork/exec; с большими файлами время в основном является временем ввода-вывода (, т. е. чтением файла с диска ). Таким образом, вы должны спросить :, как часто catиспользуется (бесполезно )в сценариях оболочки, где производительность действительно имеет значение? Сравните его с другими распространенными встроенными командами оболочки, такими как test— трудно представить, что catиспользуется (бесполезно )даже в десять раз реже, чем testиспользуется в важных местах. Это предположение, которое я не измерял, и это то, что вы хотели бы сделать перед любой попыткой реализации. (Или аналогичным образом попросить кого-то еще реализовать, например, запрос функции.)

Затем вы спрашиваете :, каковы затраты. Две затраты, которые приходят на ум, это ()дополнительный код в оболочке, который увеличивает его размер (и, следовательно, возможно использование памяти ), требует дополнительных работ по обслуживанию, является еще одним местом для ошибок и т. д. ; и (b )обратная совместимость удивляет, POSIX catопускает многие функции, например, GNU coreutils cat, так что вы должны быть осторожны, что именно будет реализовывать встроенный cat.

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

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

Постскриптум:Вы можете применить аналогичный анализ к вашему бесполезному использованию кота. Преимущества :легче читать (хотя, если command1 будет принимать файл в качестве аргумента, вероятно, нет ). Стоит :лишнее fork и exec (и если command1 может принимать файл в качестве аргумента, вероятно больше запутанных сообщений об ошибках ). Если ваш анализ говорит вам бесполезно использовать кошку, тогда вперед.