Перенаправление только stderr к каналу
Даже при том, что эти продукты типа устройства основаны на Linux, это обычно - хорошая идея не попытаться настроить их, как будто они - поля Linux. Они обычно пропускают большинство инструментов и обычно разделяются вниз различными способами, которые могут сделать это опасным.
У меня был опыт и с полем ReadyNAS Netgear, а также полями Thecus, и с это всегда имело место с обоими этими типами продуктов. Вы могли бы хотеть полагать, что выполнение восстановления фабрики возвращает это нормальное вместо того, чтобы взломать его Ваш сам.
Необходимо будет реконфигурировать поле, но это обычно просто задерживает IP и потенциально некоторое создание учетной записи пользователя.
Я направляю Вас к фактическим страницам от Synology, которые покрывают, как выполнить это:
Закройте fd3 дважды, потому что вы создаете две подоболочки в скрипте, каждая подоболочка наследуется и копирует дескриптор родительского файла. Close fd3 в каждой подоболочке не влияет на другие (и родительский тоже).
Таким образом, строка комментария очень нечеткая и вводит в заблуждение.
Если вы хотите перенаправить на конвейер только stder , вы можете использовать подстановку процесса :
ls -l 2> >(grep bad)
или поменять местами stderr и stdout ]:
ls -l 3>&1 1>&2 2>&3 | grep bad
Ни ls, ни grep не нужно ничего открывать на их fd 3 (они не используют этот fd), поэтому лучше его закрыть (освободить ненужные ресурсы). Мы используем этот fd 3 только для того, чтобы иметь возможность восстановить ls stdout до исходного (перед выполнением ls).
Помните, что в конвейере все команды выполняются одновременно в собственном процессе. Перенаправления применяются к каждой из них отдельно, поэтому закрытие fd 3 для одной не может закрыть его для другой.
На практике в этом случае нет особой разницы, закрывать или не закрывать, кроме того, что в противном случае вы можете быстрее достичь ограничения на количество файловых дескрипторов.
В других случаях (например, когда команды сами запускают другие процессы), это может задержать ресурсы и вызвать проблемы. Например, если stdout - это труба, фоновый процесс может унаследовать этот fd, не позволяя любому читателю из этой трубы увидеть EOF, пока этот процесс не вернется.
Лучше было бы написать так:
{ ls -l 2>&1 >&3 3>&- | grep bad 3>&-; } 3>&1
Таким образом, fd 3 перенаправляется только временно, на время работы этой группы команд (и восстанавливается после этого или закрывается).
Видите разницу:
$ { ls -l /proc/self/fd 2>&1 >&3 3>&- | grep bad 3>&-; } 3>&1
total 0
lrwx------ 1 stephane stephane 64 Apr 2 09:29 0 -> /dev/pts/4
lrwx------ 1 stephane stephane 64 Apr 2 09:29 1 -> /dev/pts/4
l-wx------ 1 stephane stephane 64 Apr 2 09:29 2 -> pipe:[575886]
lr-x------ 1 stephane stephane 64 Apr 2 09:29 3 -> /proc/20918/fd/
$ { ls -l /proc/self/fd 2>&1 >&3 | grep bad 3>&-; } 3>&1
total 0
lrwx------ 1 stephane stephane 64 Apr 2 09:29 0 -> /dev/pts/4
lrwx------ 1 stephane stephane 64 Apr 2 09:29 1 -> /dev/pts/4
l-wx------ 1 stephane stephane 64 Apr 2 09:29 2 -> pipe:[575900]
lrwx------ 1 stephane stephane 64 Apr 2 09:29 3 -> /dev/pts/4
lr-x------ 1 stephane stephane 64 Apr 2 09:29 4 -> /proc/20926/fd/
Во втором вызове ls имел свой fd 3 также открытым для терминала (который был открыт на stdout в то время, когда я запускал конвейер) без веской причины.
Обратите внимание, что в ksh93, с exec, вам не нужно закрывать эти fd, поскольку fd, отличные от 0, 1, 2, автоматически закрываются при выполнении команды.
$ ksh93 -c 'exec 3>&1; ls -l /dev/fd/'
total 0
lrwx------ 1 stephane stephane 64 Apr 2 09:34 0 -> /dev/pts/16
lrwx------ 1 stephane stephane 64 Apr 2 09:34 1 -> /dev/pts/16
lrwx------ 1 stephane stephane 64 Apr 2 09:34 2 -> /dev/pts/16
lr-x------ 1 stephane stephane 64 Apr 2 09:34 3 -> /proc/21105/fd
$ ksh93 -c 'exec 3>&1; ls -l /dev/fd/ 3>&3'
total 0
lrwx------ 1 stephane stephane 64 Apr 2 09:34 0 -> /dev/pts/16
lrwx------ 1 stephane stephane 64 Apr 2 09:34 1 -> /dev/pts/16
lrwx------ 1 stephane stephane 64 Apr 2 09:34 2 -> /dev/pts/16
lrwx------ 1 stephane stephane 64 Apr 2 09:34 3 -> /dev/pts/16
lr-x------ 1 stephane stephane 64 Apr 2 09:34 4 -> /proc/21108/fd
Я не знаю, почему выше написано (но не 'ls'), похоже на ошибку (возможно, мою ;-).