В интерактивном Bash foo &
запускает foo
в фоновом режиме и выводит идентификатор задания и идентификатор процесса в стандартную ошибку оболочки.
foo 2>/dev/null &
запускает foo
в фоновом режиме, stderr перенаправляется на /dev/null
, но по-прежнему выводит идентификатор задания и идентификатор процесса в стандартную ошибку оболочки (, а не на перенаправленный stderr из foo
).
{ foo & } 2>/dev/null
сначала перенаправляет stderr на /dev/null
, затем внутренняя часть {}
обрабатывается с применением этого перенаправления. Затем foo
запускается в фоновом режиме, и идентификатор задания и идентификатор процесса печатаются в , теперь перенаправленный stderr оболочки (, то есть в/dev/null
).
When commands are grouped, redirections may be applied to the entire command list.
Мы можем проверить примененное перенаправление, группа также перенаправляет вывод идентификатора задания:
$ { sleep 9 & } 2> temp [ no output here ] $ cat temp [1] 8490
Когда команда в конце концов завершается, уведомление об этом появляется на терминале, однако:(Или, скорее, в текущем стандартном потоке командной строки, чем бы он ни был.)
$ kill %1
[1]+ Terminated sleep 99
В {... } 3>&2 2>/dev/null
fd 3 перенаправляется туда, куда всегда указывает stderr, а затем stderr перенаправляется на /dev/null
. Предполагая, что stderr изначально указывал на терминал, результатом будет 3 -> terminal, 2 -> /dev/null
. Эти перенаправления применяются к группе.
Если у нас есть { foo 2>&3 & }
внутри группы, foo
запускается в фоновом режиме, его stderr указывает на fd 3 группы, а идентификатор задания и идентификатор процесса печатаются в stderr группы.
Сложив эти два вместе, foo
stderr указывает на то место, куда указывает fd 3 группы, т. е. исходный stderr, а идентификатор задания печатается в fd 2 группы, т. е. /dev/null
.
Таким образом, по сути, { 2>&3 foo & } 3>&2 2>/dev/null
перенаправляет идентификатор задания и идентификатор процесса, напечатанный оболочкой, на /dev/null
и направляет foo
stderr в обход этого перенаправления:
foo's stdout -> group's fd 1 -> original stdout (never redirected)
foo's stderr -> group's fd 3 -> original stderr
job id from group -> group's fd 2 -> /dev/null
Вы можете настроить /etc/fstab один раз со следующей записью:
/path/to/original/dir /path/to/bind/dir none bind,rw,user,noauto 0 0
Параметры монтирования определяют следующие вещи в порядке:
bind
указывает, что эта запись является привязанным монтированием. rw
указывает, что запись будет смонтирована в режиме чтения -записи. user
позволяет любому не -пользователю root монтировать файловую систему. noauto
указывает, что эта запись не должна автоматически монтироваться с помощью mount -a
и во время загрузки. Вам нужно будет настроить это один раз, используя привилегии суперпользователя. Как только запись будет на месте, вы можете выполнить монтирование как пользователь без полномочий -. Просто запустите mount /path/to/bind/dir
.
Несколько замечаний:
user
только та же учетная запись пользователя, которая первоначально смонтировала файловую систему, может выполнить размонтирование. Если задействовано несколько пользователей, вместо этого вы можете посмотреть на опцию users
. Подробности см. в man 8 mount
. user
подразумевает три других параметра:noexec
(не разрешать выполнение двоичных файлов ),nosuid
(не учитывать биты setuid/setgid )иnodev
(не интерпретировать устройства ). Если вы хотите восстановить какую-либо из этих функций, добавьте соответствующую опцию в конец списка. Например, bind,rw,user,noauto,exec
. Имейте в виду, что эти параметры влияют на безопасность. Подробности см. в man 8 mount
. Это можно сделать с помощью различных утилит FUSE. Например, bindfs может смонтировать каталог в другое место, аналогично тому, что сделал бы mount --bind
.
bindfs --no-allow-other /source/directory /mount/point
Параметр --no-allow-other
необходим, если вы не раскомментируете user_allow_other
в /etc/fuse.conf
(, но см. ниже примечание о libfuse для безопасности ).
Размонтировать с помощью:
fusermount -u /mount/point
Обратите внимание, что файловые системы FUSE в настоящее время имеют известные проблемы/ограничения. Стоит упомянуть, среди прочего, стоимость производительности, невозможность использования inotify для мониторинга событий файловой системы, происходящих в исходной файловой системе, и последствий для безопасности, перечисленных в README libfuse GitHub .
В Linux монтирование с привязкой , выполненное как mount --bind
, не будет иметь этих недостатков. Но для редактирования вашего fstab
потребуются привилегии root хотя бы один раз.
Обратитесь к связанному Q/A для гораздо более подробного освещения предмета.