Перенаправление файлового дескриптора 3 с тройником - PullRequest
4 голосов
/ 16 февраля 2011

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

sudo rsync -xPRSaz --rsync-path='sudo rsync' maeve@macbook:/ macbook/ 3>&1 1>&2 2>&3 | tee macbook.log

Я не могу найти какой-либо специальной обработки дескриптора файла 3 для sudo, rsync или tee. После переадресации в настоящее время я предполагаю, что это ситуация:

now fd points to old fd
     0    -->         0
     1    -->         2
     2    -->         1
     3    -->         1
  • Применяются ли эти перенаправления к sudo или к rsync и с какой целью?
  • Является ли файловый дескриптор 3 закрытым или зависать каким-либо "плохим" способом?

Ответы [ 2 ]

1 голос
/ 21 февраля 2011

Обратите внимание, что дескриптор оборванного файла 3 можно закрыть с помощью 3>&-, вот полная строка с включенным:

sudo rsync -xPRSaz --rsync-path='sudo rsync' maeve@macbook:/ macbook/ 3>&1 1>&2 \
2>&3 3>&- | tee macbook.log
1 голос
/ 16 февраля 2011

Ваше предположение верно.Это довольно ловкий трюк, чтобы поменять местами стандартный вывод и стандартную ошибку.Чтобы ответить на ваши вопросы:

  • эти перенаправления перехватываются оболочкой, поэтому они применяются к той части конвейера (которая sudo).Сам процесс sudo обнаружит все аргументы и передаст их своей подкоманде (rsync), но перенаправления были захвачены и обработаны до этого момента: sudo никогда их не видит.ручка 3 не оставлена ​​висящей.Он будет закрыт по окончании процесса.
...