Создание временного файла по сравнению с заменой процесса по сравнению с переменным расширением?

<(cmd) a ksh функция, также найденная в наше время в zsh и bash названная замена процесса.

В системах та поддержка /dev/fd/n или /proc/self/fd/n, это реализовано с каналами и если не с временными именованными каналами. В любом случае это - форма канала, который является механизмом межпроцессорного взаимодействия.

cmd1 <(cmd2)

Может быть записан (с нормальными каналами):

{ cmd2 4<&- | 3<&0 <&4 4<&- cmd1 /dev/fd/3; } 4<&0

Или (с именованными каналами):

mkfifo /tmp/named_pipe
cmd2 > /tmp/named_pipe & cmd1 /tmp/named_pipe

Таким образом, обе команды запускаются одновременно и общаются с каналом. Вы обычно использовали бы cmd2 | cmd1 для этого, но замены процесса обычно для тех случаев где cmd1 может только взять вход от имени файла а не от стандартного входа или когда больше чем один вход необходим как в diff <(cmd1) <(cmd2).

Нет никакого rlimit влияния на него кроме общих как на количестве процессов, процессорное время или память.

PIPEBUF, о котором сообщают некоторые реализации ulimit как bash и некоторые реализации ksh не rlimit, но максимальный размер, для которого запись к каналу, как гарантируют, будет атомарной, так не важно здесь. Размер самого канала (64 КБ на Linux, как сообщается @dsmsk80) не является действительно самим пределом. Это просто говорит, что это так же cmd2 может записать в канал даже после cmd1 прекратил читать из него.

Существует ограничение хотя в этом cmd1 может только читать из того файла. Поскольку это - канал, это не может записать в тот файл или искать назад и вперед в файле.

zsh имеет третью форму замены команды с помощью регулярных временных файлов:

cmd1 =(cmd2)

вызовы cmd1 с временным файлом, который содержит вывод cmd2. В этом случае cmd1 бежится cmd2 вместо одновременно. Предел на размер файлов может быть достигнут там.

Я не знаю ни о какой оболочке, реализовывая a <<<(...) оператор. Существует однако a <<< оператор в zsh (вдохновленный тем же оператором в порте Unix rc) также найденный в последних версиях ksh93 и bash. Это - вариация на << оператор heredoc, названный herestring.

В:

cmd <<< something

Который совпадает со стандартом:

cmd << EOF
something
EOF

Оболочка создает временный файл с something\n как содержание и подача, что, поскольку стандартный вход к новому процессу, удаляет связь с тем файлом и выполняется cmd в том новом процессе. Снова, это - регулярный файл, таким образом, rlimit на максимальном размере файла может быть достигнут.

Теперь можно объединиться <<< оператор с $(...) (управляйте заменой) так или иначе эмулировать zsh =(...) оператор в bash и ksh93:

cmd1 <<<"$(cmd2)"

Работал бы cmd2 с ним stdout, перенаправленный к каналу. На другом конце канала оболочка читает вывод cmd2 и хранилища это минус запаздывающие символы новой строки и с одним символом новой строки, добавленным во временный файл и вызов cmd1 с тем временным файлом, открытым для чтения как stdin (примечание существует другое ограничение, в котором это не будет работать если cmd2 вывод содержит символы NUL).

Быть похожими =(...), необходимо было бы записать это:

cmd1 /dev/fd/3 3<<<"$(cmd3)"

Обратите внимание, что оболочка должна считать целый вывод cmd3 в памяти прежде, чем записать это во временный файл, таким образом, в дополнение к максимальному размеру файла, можно также достигнуть предела на использование памяти.

Также обратите внимание что начиная с версии 5, bash разделяет полномочия записи во временный файл перед вызовом cmd1, таким образом, если Вам нужно cmd1 чтобы смочь изменить тот файл, необходимо было бы работать вокруг этого с:

{
  chmod u+w /dev/fd/3 && # only needed in bash 5+
  cmd1 /dev/fd/3
} 3<<<"$(cmd3)"