Потому что это не бесполезно.
В случае cat file | cmd
fd0
(stdin )из cmd
будет каналом, а в случае cmd
Конвейер имеет семантику, отличную от семантики обычного файла, и его семантика не является подмножеством семантики обычного файла:
обычный файл нельзя select(2)
редактировать или poll(2)
редактировать осмысленным образом; a select(2)
на нем всегда будет возвращать «готово». Расширенные интерфейсы, такие как epoll(2)
в Linux, просто не будут работать с обычными файлами.
в Linux есть системные вызовы (splice(2)
, vmsplice(2)
, tee(2)
), которые работают только с каналами [1]
Поскольку cat
так часто используется, его можно было бы реализовать как встроенную оболочку -, в которой не будет дополнительного процесса, но как только вы начнете этот путь, то же самое можно будет сделать с большинством команд --. ] превращая оболочку в более медленную и громоздкую perl
или python
. возможно, лучше написать другой язык сценариев с простым в использовании синтаксисом -типа конвейера для продолжений ;-)
[1] Если вам нужен простой пример, не придуманный по случаю, вы можете посмотреть мой "exec binary from stdin" git gist с некоторыми пояснениями в комментарии здесь . Реализация cat
внутри него, чтобы заставить его работать без UUoC, увеличила бы его в 2 или 3 раза.