Проверка правильности дескриптора файла

Я бы хотел, чтобы скрипт bash выводил дополнительную информацию в файловые дескрипторы (FD), большие или равные 3, когда они открыты. Чтобы проверить, открыт ли FD, я разработал следующий трюк:

if (printf '' 1>&3) 2>&-; then
  # File descriptor 3 is open
else
  # File descriptor 3 is not open
fi

Этого достаточно для моих нужд, но мне любопытно, есть ли более идиоматический способ проверки, действителен ли FD. Меня особенно интересует, существует ли отображение fcntl(1)системного вызова на команду оболочки, которая позволила бы извлекать флаги FD ( O_WRONLYи O_RDWRпроверять, является ли FD доступным для записи, и O_RDONLYи O_RDWRпроверять, является ли FD читаемым).

В ksh(варианты AT & T и pdksh) или zsh, вы можете сделать:

if print -nu3; then
  echo fd 3 is writeable
fi

Они не будут ничего писать на этом fd, но все же проверят, доступен ли для записи fd (использует fcntl(3, F_GETFL)) и сообщают об ошибке в противном случае

$ ksh -c 'print -nu3' 3< /dev/null
ksh: print: -u: 3: fd not open for writing

(который вы можете перенаправить на /dev/null)

С помощью bash, я думаю, ваш единственный вариант - проверить, dup()успешно ли, как в вашем подходе, хотя это не гарантирует, что fd доступен для записи (или вызвать внешнюю утилиту ( zsh/ perl...) для этого fcntl()).

Обратите внимание, что в bash(как и большинство оболочек), если вы используете (...)вместо этого {...;}, это будет форкировать дополнительный процесс. Ты можешь использовать:

if { true >&3; } 2<> /dev/null

вместо этого, чтобы избежать форка (за исключением оболочки Bourne, где перенаправление составных команд всегда вызывает подоболочку). Не используйте :вместо trueэтого специальную встроенную функцию , так как это приведет к закрытию оболочки, когда bash находится в режиме соответствия POSIX.

Однако вы можете сократить его до:

if { >&3; } 2<> /dev/null

В описании использования приложения POSIX вы найдете следующее:command

Есть некоторые преимущества в подавлении особых характеристик специальных встроенных элементов в некоторых случаях. Например:

command exec > unwritable-file

не приводит к прерыванию неинтерактивного сценария, поэтому сценарий может проверить состояние вывода.

Вот почему вы можете просто сделать:

if    command >&3
then  echo 3 is open >&3
else  ! echo 3 is not open
fi    2<>/dev/null

Или...

{ command >&3
  printf %s\\n%.0d  string "0$(($??8:0))" >&"$(($??1:3))"
} 2<>/dev/null

Который будет записывать строку, за которой следует электронная \nстрока, либо в stdout, либо в 3, и все равно передавать ненулевой статус выхода, когда 3 не открыта, потому что математика, выполненная в $?результате, не в состоянии преобразовать восьмеричный 08 в десятичный%, но обрезает до нуля вообще восьмеричное 00 .

Или...

command exec >&3 || handle_it

Но если вы используете ksh93, вы можете просто сделать:

fds

Для списка открытых файловых дескрипторов. Добавьте, -lчтобы увидеть, куда они идут.

Дескрипторы открытых файлов можно найти в /proc/<pid>/fd. Например, перечислить дескрипторы открытых файлов текущей оболочки, ls -l /proc/$$/fdкоторые должны дать вам что-то вроде:

total 0
lrwx------ 1 testuser testuser 64 jun  1 09:11 0 -> /dev/pts/3
lrwx------ 1 testuser testuser 64 jun  1 09:11 1 -> /dev/pts/3
lrwx------ 1 testuser testuser 64 jun  1 09:11 2 -> /dev/pts/3
lrwx------ 1 testuser testuser 64 jun  1 09:39 255 -> /dev/pts/3

Когда вы открываете файл с помощью:

touch /tmp/myfile
exec 7</tmp/myfile

Должен быть указан новый ls -l /proc/$$/fd:

lr-x------ 1 testuser testuser 64 jun  1 09:11 7 -> /tmp/myfile

Если вы закроете файловый дескриптор снова, exec 7>&-его тоже не будет в списке /proc/$$/fd.

Ваш трюк выглядит мило; но для идиоматического способа мне интересно, почему вы не использовали:

if ( exec 1>&3 ) 2>&-

Если вы заинтересованы в решении с низким уровнем разветвления, чтобы использовать его повторно, я бы предложил эту функцию:

checkfd () {
    exec 2> / dev / null
    если exec> & 3; тогда
        exec 1> / dev / tty
        echo "fd3 OK"
    еще
        эхо "fd3 KO"
    фи
    exec 2> / dev / tty
}

И вот что он производит с zsh:

$ checkfd            
FD3 KO
$ checkfd 3> / dev / null
fd3 ОК
$

Это кажется очень простым (см. Комментарии):

[ -r /proc/$$/fd/$FD ] && echo "File descriptor $FD is readable"
[ -w /proc/$$/fd/$FD ] && echo "File descriptor $FD is writable"

В качестве дополнительного ... Тест [-r file] не указывает, действительно ли какие-либо данные ожидают чтения (/ dev / null проходит этот тест (см. Комментарии)).

[ -r /proc/$$/fd/4 ] \
  && [ read -t 0.0001 -N 0 <&4 ] \
  && echo "Data is waiting to be read from file descriptor 4"

Требуется некоторое небольшое число для аргумента тайм-аута (read -t), или могут быть пропущены данные, которые требуют некоторого вычисления. Требуется читаемый тест ([-r файл]) или команда чтения будет бомбить, если файл не читается. Это на самом деле не будет читать какие-либо данные, потому что число байтов равно нулю (чтение -N 0).

Вопрос довольно старый - но так или иначе - почему бы просто не использовать встроенные функции?

for i in {0..5} ; do if [ -t $i ]; then echo "$i is a valid FD"; else echo "$i is INVALID FD"; fi; done

Выход:

0 is a valid FD
1 is a valid FD
2 is a valid FD
3 is INVALID FD
4 is INVALID FD
5 is INVALID FD

Итак, чтобы ответить на вопрос - предлагаю:

if [ -t 3 ]; then
  # File descriptor 3 is open
else
  # File descriptor 3 is not open
fi