Почему не может я 'хвост-f/proc/$pid/fd/1'?
Обычно find не изменяет время доступа файла.To, получают время изменения и время доступа для файла, который можно использовать stat команда
например:
$ stat filename
Вывод
File: `filename'
Size: 683 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 34177055 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2012-11-26 03:50:01.000000000 -0500
Modify: 2012-11-26 03:22:04.000000000 -0500
Change: 2012-11-26 03:22:04.000000000 -0500
Сделайте стропу из хвоста -f , это все объясняет. Интересная часть:
13791 fstat(3, {st_mode=S_IFREG|0644, st_size=139, ...}) = 0
13791 fstatfs(3, {...}) = 0
13791 inotify_init() = 4
13791 inotify_add_watch(4, "/path/to/file", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1
13791 fstat(3, {st_mode=S_IFREG|0644, st_size=139, ...}) = 0
13791 read(4, 0xd981c0, 26) = -1 EINTR (Interrupted system call)
Что она делает? Он устанавливает обработчик inotify к файлу, а затем ждет, пока с этим файлом что-нибудь случится. Если через этот обработчик инотификатора ядро сообщает tail, что файл изменился (обычно, был добавлен), то tail 1) ищет 2) читает изменения 3) записывает их на экран.
/proc/3844/fd/1 в вашей системе является символической ссылкой на /dev/pts/14, который является символьным устройством. Нет такой вещи, как "карта памяти", к которой можно было бы получить доступ. Таким образом, нет ничего, изменения которого могли бы быть подписаны в уведомлении, потому что нет ни диска, ни области памяти, к которой можно было бы получить доступ с помощью этого.
Это символьное устройство представляет собой виртуальный терминал, который практически работает как сетевое сокет. Программы, запущенные на этом виртуальном терминале, подключаются к этому устройству (так же, как если бы вы подключили telnet-ted к tcp-порту) и записывают то, во что они хотят записать. Есть и более сложные вещи, например, блокировка экрана, последовательности управления терминалом и так далее, они обычно обрабатываются вызовами ioctl().
Я думаю, вы хотите как-то посмотреть на виртуальный терминал. Это можно сделать на linux, но это не так просто, это требует некоторой сетевой прокси-подобной функциональности, и немного хитрого использования этих вызовов ioctl(). Но есть инструменты, которые могут это сделать.
В настоящее время я не могу вспомнить, в каком пакете debian есть инструмент для этой цели, но с помощью небольшого гуглинга вы можете легко это найти.
Расширение: , как @Jajesh упоминается здесь (дайте ему +1, если вы дадите мне), инструмент называется watch.
Расширение #2: @kelnos упоминалось, простого cat /dev/pts/14 также было достаточно. Я попробовал, и да, это сработало, но неправильно. Я не много экспериментировал с этим, но мне кажется, что выход, идущий в этот виртуальный терминал, идет либо на команду cat, либо на ее исходное местоположение, и никогда на оба. Но в этом нет уверенности.
Файлы в / dev / pts не являются обычными файлами, это дескрипторы для виртуальных терминалов.
Поведение pts для чтения и записи не является симметричным (то есть то, что там написано, может быть позже прочитано из него, как обычный файл или FIFO / pipe), но опосредовано процессом, который создал виртуальный терминал: некоторые из распространенных - xterm, ssh, agetty или screen. Процесс управления обычно отправляет нажатия клавиш процессам, которые читают файл pts , и отображают на экране то, что они пишут в pts .
Таким образом, tail -f / dev / pts / 14 напечатает ключи, которые вы нажимаете на терминале, с которого вы запустили свой скрипт, и если вы сделаете echo meh> / dev / pts / 14 сообщение meh появится в терминале.
Наверное, для этого, а не для хвоста, нужно следить за выходом.
$ watch -n2 ls -l /proc/3844/fd/
Надеюсь, это то, что вам нужно.
Некоторое время назад я нашел что-то вроде обходного пути, который иногда отвечает необходимости проверять, что выводится в STDOUT, при условии, что у вас есть pidпроцесса и вы можете неблагоприятные для глаз результаты:
sudo strace -p $pid 2>&1 | grep write\(