C++ читать перенаправленный поток

ЯННП.

Ты хочешь запустить программу, и потом передавать запущенной программе команды?

А может хватит сигналов? Если нет - не выёживайся, используй сокеты.

Возможно, ты прав! )

Хотя сокеты универсальнее, с пайпами начать будет проще.

Ты со второй консоли запускаешь второй экземпляр процесса, это так задумано? Выглядит странно. Если говорить о pipe (я имею в виду заранее созданный и именованый), это могло бы выглядеть так:

#./my_programm & #«started»

консоль 2: #echo «command 1» > /var/run/my_pipe #

консоль 1: #«command 1 processed»

Но как бы там ни было, если собираешься использовать пайпы, сокеты, придется использовать отдельные потоки для их обработки, с сигналами проще чуть-чуть, но синхронизация тоже понадобится. А судя по вопросу, тебе еще предстоит это почитать. Я прав? :-)

используй сокеты

Пора уже бить по рукам за сокеты. Будешь выпендриваться, буду резать бритвой... Оккама.

2ТС: pipe наше всьо!

А если человек пишет демон которым понадобится управлять удаленно? А если это кросплатформенное решение, которое надо будет запускать под оффтопиком?

Не надо по рукам бить. :-)

А если это кросплатформенное решение, которое надо будет запускать под оффтопиком?

Сокеты более кросплатформенное решение, чем пайпы? Вот те раз. А мужики-то не знают!

Про трудоёмкость я вообще молчу.

Про трудоёмкость я вообще молчу.

А в чём трудоёмкость? Библиотек для сокетов навалом, с готовым запуском сервера xmlrpc или, там, http, в пол-пинка. Зачем колхозить что-то на пайпах, если можно нахаляву получить сетевую прозрачность и стандартный протокол управления?

Хм, каюсь, под оффтопик не писал лет 10 наверное, таки можно и с пайпами, но!.. разница в апи огромная, в то время как разница работы с сокетами минимальная, а это именно то, что я и имел в виду.

Сетевые задержки тоже библиотеки будут обрабатывать? Опять же: ты статически собрался линковать?

Библиотек для сокетов навалом, с готовым запуском сервера xmlrpc или, там, http, в пол-пинка.

А для FIFO и библиотек не нужно.

Делай модульно. Объект-поток. Реализуешь потом хоть квантовый телепортатор.

А ещё есть традиция перечитывать конфиг по USR1.

Сетевые задержки тоже библиотеки будут обрабатывать?

При чём тут какие-то задержки? Ну какая там задержка на localhost, у меня ~50мкс. Это что, ограничивающий фактор?

Опять же: ты статически собрался линковать?

А для пайпа ты через системные вызовы собрался дергать? Сокеты тоже так можно.

При чём тут какие-то задержки? Ну какая там задержка на localhost, у меня ~50мкс.

Дальше мог бы и не продолжать.

и библиотек не нужно.

http или xmlrpc на пайпах без библиотек? Я и говорю - колхоз.

Дальше мог бы и не продолжать.

Да, собственно на твой тупой вопрос вообще можно было не отвечать.

http или xmlrpc

Откуда взялась необходимость этих достойных протоколов - из твоих фантазий?

Да, собственно на твой тупой вопрос вообще можно было не отвечать.

Если ты чего-то не понимаешь это не значит, что все вокруг дураки. Это значит, что ты дурак.

2ТС: pipe наше всьо!

а вот интересно, что именно вы подразумеваете под этим «вашем всьо»?

Рабочий совет?

что вы называете pipe`ом я хотел спросить

Ну-ну. Столько звёзд и не знаешь что такое pipe... Да вытроль, батенька.

Между тем, этот персонаж не раз был замечен за раздачей дельных советов.

Столько звёзд и не знаешь что такое pipe

А 2 звезды устороят? Объясни мне про пайпы, особенно в контексте старт поста темы

cin

http://www.cplusplus.com/reference/iostream/cin/

(или fread(3) из /dev/stdin, если не любишь STL)

Посмотрел в сторону pipe, но не уверен, что оно подойдет для этих целей. Возможно, плохо смотрел.

#./my_programm <<«command 1»

а это что по твоему? Хотя ИМХО более разумно написать echo 'command 1' | ./my_prog