Тестування, чи правильний дескриптор файлу

Я хотів би зробити виведення сценарію 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

Який буде писати рядок з наступною \newline або 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
        ехо "fd3 ОК"
    ще
        відлуння "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 файл]), або команда читання спрацює, якщо файл не читається. Це фактично не буде читати жодних даних, оскільки кількість байтів дорівнює нулю (read -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