Почему вход в канал хорошо подходит для zenity, но <файловые неполадки?

Мой вопрос так же прост, как то, что говорят zenity --text в примере … но что вызывает этот 100% захват процессора при перенаправлении?
… (и, кстати, это конкретное использование < фактически называемого redirection . Похоже, что он создает направление, а не переадресацию).

 echo "Peacocks talking of the colour grey."> test cat test | zenity --text='This does NOT hog the CPU' --list --column='#' --width=450 <test zenity --text='This hogs 100% of CPU usage' --list --column='#' --width=450 

Я очень рад использовать cat test | (потому что в этом случае он не бесполезен, он работает и <и | как-то отличается, но я еще не смог отследить его снова …

Быть ясным: <test и cat test | обе работа. Диалог zenity появляется и полностью функционирует в обоих случаях, но до тех пор, пока <test версия диалога остается открытой, она использует 100% CPU (одного ядра) … 94% для одиночных «основных» виртуальных машин …

  • Сделать окно сообщения zenity масштабируемым?
  • GTK: задание цвета переднего плана и фона в командной строке
  • Что-то не так с пространством в zenity, пытающимся создать скрипт
  • Отображение отрицательных чисел в zenity -list
  • YAD и Zenity - ввод времени начала / остановки для обрезания видео
  • Zenity отказывается работать в фоновом режиме
  • Завершить скрипт с помощью индикатора прогресса zenity
  • Как отобразить диалоговое окно (zenity / GUI) пользователю после завершения задачи cron cron
  • 2 Solutions collect form web for “Почему вход в канал хорошо подходит для zenity, но <файловые неполадки?”

    Это похоже на ошибку в зените. Вы можете видеть, что происходит, используя инструмент strace (я обернул линии strace в этом посте, чтобы было легче читать).

    С версией трубы эта линия в strace показывает, что происходит, когда труба закрыта (потому что cat выходит):

     poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=0, events=POLLIN}], \ 3, 0) = 1 ([{fd=0, revents=POLLIN|POLLHUP}]) 

    Эта часть в конце – fd=0, revents=POLLIN|POLLHUP , в частности POLLHUP – сообщает, что stdin повесил трубку (писатель трубы ушел). Zenity обрабатывает это правильно и закрывает fd 0 позже.

    Файлы не получают события POLLHUP – вместо этого результат read(2) равный нулю, означает EOF. Это другой путь кода для zenity. Он снова опробуется для fd 0, и это то, что он получает:

     poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=0, events=POLLIN}],\ 3, 0) = 1 ([{fd=0, revents=POLLIN}]) read(0, "", 1024) = 0 

    Это должно быть концом этого – чтение нуля должно заставить zenity закрыть fd 0. Но это не так. Вывод strace выше продолжает повторяться, так как zenity продолжает опрос fd 0. Пока fd 0 не будет закрыт, он всегда будет готов к чтению, так как файловые дескрипторы в EOF работают, так как вам нужно прочитать его, чтобы получить результат EOF.

    Поскольку zenity не отвечает правильно EOF на stdin, он продолжает цикл в цикле poll(2) / read(2) , где poll немедленно возвращается, как и read . Снова и снова и снова…

    Попробуй это:

     zenity --text='This does NOT hog the CPU' --list --column='#' --width=450 <(cat test) 
    Interesting Posts
    Linux и Unix - лучшая ОС в мире.