Существуют ли «исполняемые» файловые системы?

Нет. И такая файловая система была бы совершенно бесполезна.

Например, :, если sedбудет в этой файловой системе, как будет работать ls | sed 's/a/b'? Оболочка откроет sedдля выполнения, но вместо этого файловая система вернет STDOUT sed. Однако в файловой системе нет STDIN для sed, так что теперь все зависает(sedв ожидании STDIN )или выходит (пустым STDIN дляsed)без каких-либо действий.

Это тоже проблема XY.

Не следует пытаться решить проблемы со сценариями, изменяя поведение файловой системы.

Как предположил @Arkadiusz Drabczyk, ваша проблема была бы решена заменой процесса. Например :, если вы хотите сделать

sort file1 | uniq >tmp1
sort file2 | uniq >tmp2
diff tmp1 tmp2 

но вы не можете или не хотите создавать временные -файлы tmp1и tmp2, вы можете

diff <(sort file1 | uniq) <(sort file2 | uniq)

Дополнительный пример, который немного похож на ваш вопрос :Предположим, у меня есть файл inputfileс:

a:b:c:d
i:j:k:l
e:f:g:h

и у меня есть простой демонстрационный скрипт с:

#!/bin/bash
filename=$(echo $* | sed 's/.*credentials=//;s/,.*//')
echo "The filename is: $filename"
echo "The contents is:"
cat $filename

Тогда, очевидно, я мог бы:

./procsub.sh -fstype=cifs...,rw,credentials=inputfile,,... ://remote

, а вывод будет:

a:b:c:d
i:j:k:l
e:f:g:h

Однако я мог бы также, например, если бы я хотел отсортировать вывод, сделать:

./procsub.sh -fstype=cifs...,rw,credentials=<(sort inputfile),,... ://remote

и тогда вывод будет:

The filename is: /dev/fd/63
The contents is:
a:b:c:d
e:f:g:h
i:j:k:l

Надеюсь, это немного прояснит ситуацию.

Хорошо, давайте посмотрим, правильно ли я понял :У вас есть некоторые данные в LDAP, которые ссылаются на какое-то имя файла (среди прочего ). Предположительно, этот файл находится в каком-то сетевом ресурсе, доступном для чтения всем хостам, использующим этот каталог LDAP, и вы хотите, чтобы содержимое файла создавалось динамически. Так, например. каталог содержит credentials=/ldap/foo.cred, и когда какая-то система открывает /ldap/foo.cred, они получают динамические данные.

По-видимому, существует программа под названием ScriptFS , реализация FUSE (Filesystem in Userspace)практически точно того, что вы просите, но я не знаком с этим инструментом., и не знаю, насколько хорошо это работает. (@KamilMaciorowski упомянул об этом в комментарии и в своем ответе на суперпользователя.)

ScriptFS is a new file system which merely replicates a local file system, but replaces all files detected as "scripts" by the result of their execution.

FUSE, как следует из названия, позволяет программе пользовательского пространства реализовывать файловую систему, как и любую другую, а ядро ​​организует передачу запросов на доступ к файлу процессу, ответственному за работу с файловой системой. Это позволит генерировать произвольный динамический контент. Предположительно, он также будет работать в сетевых ресурсах, поскольку файлы отображаются как обычные файлы, но у меня нет личного опыта его использования.

Из более «традиционных» функций наиболее близкими являются именованные каналы и именованные сокеты.

Именованные каналы, созданные с помощью mkfifo, аналогичны каналам, которые вы используете при выполнении somecmd | grep foo, за исключением того, что они имеют имя в файловой системе и могут быть открыты оттуда. Так что вы можете написать mkfifo p; somecmd > p & grep foo < p. Или аналогичным образом читатель может открыть его первым. И читатели, и писатели блокируются до тех пор, пока на другом конце не появится кто-то. Поначалу кажется, что он может делать то, что вы хотите, вы можете настроить программу для записи в конвейер и выдавать текущий вывод, когда кто-то открывает его для чтения. Однако каналы существуют только один раз, поэтому одновременные пользователи будут подключаться к одному и тому же потоку. Кроме того, я совершенно не понимаю, как они работают с сетевыми ресурсами.Возможно, канал будет существовать только на стороне клиента, поэтому оба конца должны быть в одной системе.

Сокеты домена Unix также могут существовать с именем в файловой системе (, если вы используете systemd, вы, вероятно, можете найти несколько под/run). При подключении процесс открытия подключается к процессу, прослушивающему сокет (, как и при TCP-соединении ). Соединения здесь независимы, но загвоздка в том, что (AFAIK )сокеты домена Unix не могут быть открыты с помощью open(), но должны быть подключены к connect(). Следовательно, вы не можете сделать cat < socket, это не сработает.