|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 22 Jan 2003 22:02:58
To : Vladimir Bormotov
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Jan 22 15:23 03, Vladimir Bormotov wrote to Zahar Kiselev:
ZK>>>> Вот я тоже на это обратил внимание. И возникли вопросы: он что,
ZK>>>> может рисовать график прямо в процессе поступления данных от
ZK>>>> программы или сначала получит все данные(программа должна выдать
ZK>>>> "конец файла"), а потом нарисует?
VB>>> тебе что, не все ответы доходят?
VB>>> 2. Запусти простой скрипт:
VB>>> while (true); do echo "plot \"data.dat\""; sleep 10; done | gnuplot
ZK>> Скорее ты невнимательно читал. Это способ рисовать график по данным
ZK>> _из_файла_, пусть и "пополняемого".
VB> ухты. Да, в такие тонкости я невчитывался.
А я вот влез в тонкости. И как оказалось - это работает. Сегодня сидел в офисе
информагентства на толстом канале и нашел даже исходник на Си, где реализованы
функции "подсовывания" команд и данных на stdin гнуплота чтобы он их рисовал.
Лежит здесь: http://ndevilla.free.fr/gnuplot
ZK>> А в инструкции к gnuplot есть упоминание о возможности брать данные с
ZK>> stdout программы. Вот про _эту_ возможность и был мой вопрос.
VB> с момоента знакомства с unix, я искренне верю, что stdin/stdout это
VB> точно такие-же файлы, как и все другие.
Вот тогда тебе-то я и задам следующий вопрос.
В описании к вышеупомянутому исходнику сказано, что сделан он на основе "трубы"
(pipe) и из-за ее однонаправленности нет возможности получать в программу
информацию о результате выполнения команды. В моем случае важен
сам факт окончания исполнения текущей команды - чтобы не "кормить" гнуплот
данными быстрее, чем он их в состоянии пережевывать(а делает он это в случае
простого двумерного графика весьма быстро). Только вот кажется мне, что в данном
случае имеет место не ограничение системы на однонаправленность трубы, а
недостаточная квалификация того кто это писал(либо ему было не надо).
Отсюда возникла мысль - поразбираться в механизме переназначения stdin/stdout
для запускаемой посредством fork/exec программы и "подключиться" не только к ее
stdin, но и к stdout тоже. Чтобы после запуска можно было в один дескриптор
писать команды, а из другого получать ответы. А программа(гнуплот в моем случае)
рисует графики на иксовом экране.
Остается подсмотреть где-нибудь как одновременно переназначить stdin и stdout
запускаемой программы и отдать "ручки управления"(хэндлы) родительскому
процессу. Только не предлагай исходник bash изучать - он немного великоват будет
в качестве учебного пособия:-)
Вообще-то как минимум один способ мы с приятелем лет пять назад нашли и
использовали - через пару псевдотерминалов. Программка та и сейчас работает.
Благодаря ей mgetty на моей фидошной машине использует ttypX, отвечая "поверх
IP" на заданном порту. Hо у mgetty терминал - это не совсем то, что у обычной
программы stdin/stdout. Даже запущенное с консоли, mgetty _само_ себе
переназначает управляющий терминал. А большинство прочих программ, общающихся с
пользователем через командную строку - такого самопереназначения делать не
умеют. Следовательно надо где-то подсмотреть - что надо сделать между fork и
exec в порожденном процессе чтобы получить нужное переназначение. Видел однажды
исходник, там был трюк с _закрытием_ stdout и открытием "трубы". В результате
открываемый дескриптор попадал на "первое свободное" место, то есть как раз на
место закрытого стандартного вывода и становился стандартным выводом. Вот только
не знаю, насколько подобные предположения правомерны - всегда ли это сработает.
VB>>> Этот скрипт будет каждые 10 секунд заставлять ОДИH И ТОТ ЖЕ гнуплот
VB>>> перерисовывать график с учётом новый данных.
ZK>> В моем случае 10 секунд - многовато. Понимаю, что десять раз в
ZK>> секунду - не реально, ну хотябы раз в секунду.
VB> заменяет sleep 10 на sleep 1
Судя по моим экспериментам - похоже и десять раз в секунду работать может если
график простой! Hадо только озаботиться синхронизацией, чтобы не "перекормить"
гнуплот данными.
ZK>> Похоже, что вышеупомянутой возможностью никто из присутствующих
ZK>> пользоваться не пробовал. Придется засесть за эксперименты.
VB> эксперементы займут ооочень много времени, аж минут 10-ть.
Да нет, побольше.
VB> Hе, ну я могу ее понять, когда знакомый физик спрашивает у меня, "не
VB> знаешь как в gnuplot сдалать что-то там, вот у меня получается это и
VB> то, но хочется скомбинировать", и за то время, что он продолжает
VB> мучаться, я успеваю поставить у себя gnuplot, посмотреть что он там
VB> умеет, поиграться с вариантами комбинирования, и ответить ему...
VB> Hо ты ведь, не такой далекий от программинга человек... Hе, не
VB> понимаю.
Вот тем профессионал и отличается. А я не понимаю, как мои знакомые
профессионалы с _такой_ скоростью разбираются в софте или сами код пишут.
Вобщем-то ничего сверхъестественного они не делают, я и сам так могу, но только
раз в пять медленнее. Однако и обратные примеры есть - на прошлой неделе я нашел
и устранил две небольшие неисправности в двухсоткиловаттном
дизель-генераторе быстрее, чем бестолково болтавшиеся вокруг четыре штатных
механика сообразили что же я вообще делаю:-) Вот они от моей производительности
труда обалдевают не меньше, чем я от твоей:)
Кстати именно эта большая железка служит "подопытным кроликом", и графики,
нарисованные гнуплотом, будут посвящены именно ее поведению:)
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.0
* Origin: Остров Большой Березовый: http://birch-island.spb.ru (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
