Совместное перенаправление stdout и stderr VS перенаправление stdout, а затем stderr в файл stdout
Похоже, проблема возникла из-за синтаксиса правила udev.
После использования внешнего скрипта вместо прямого вызова /bin/mountи добавления некоторых журналов я заметил, что в скрипт была передана только опция relatime.
После изменения правила udev на:
[...]
# Global mount options
ACTION=="add", ENV{mount_options}="relatime,utf8,uid=1000,gid=1000,dmask=0000,fmask=0000"
# Mount the device
ACTION=="add", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/usb"
[...]
Правила udev работают и монтируют USB-накопитель с ожидаемыми разрешениями.
Похоже, невозможно переопределить переменную среды в правиле udev после того, как она была определена (или я использую неправильный синтаксис ).
Если кто-то знает, как сохранить параметры монтирования файловой системы, я был бы рад увидеть это.
В противном случае этого обходного пути достаточно для моего случая, даже если он не оптимален.
Вторая форма совместима с POSIX -и будет работать в любой оболочке POSIX.
Первая форма полностью эквивалентна, но она будет работать только в оболочках, поддерживающих сокращенную форму (Bash и Zsh, если назвать две ), и не будет работать в других (Dash, например, /bin/shреализация, используемая в Debian и его производных ).
Если переносимость важна, следует использовать двухэтапную -форму.
В оболочках bashи zshнет никакой разницы между ними. Перенаправление &>file— это синтаксический сахар, реализованный как расширение стандарта POSIX, что означает то же самое, что и стандарт >file 2>&1.
Обратите внимание, что использование перенаправления &>в скрипте, выполняемом интерпретатором, отличным от -bash/zsh, вероятно, нарушит ваш скрипт интересным образом, так как &и >будут интерпретироваться независимо друг от друга..
some_command &>file
в сценарии, отличном от -bash/ zsh, будет таким же, как
some_command & >file
и как
some_command &
>file
Это запускает some_commandкак фоновое задание и усекает/создает файл с именем file.
Также связанные: