Проще так делать, когда нужно такое специфичное поведение:

cat <(echo "text") - | mybinary

И похоже после EOF с потоком вообще нельзя никак работать. Верно ли эта мысль?

А смысл с ним работать, если в нём ничего больше нет?

или существует способ в рамках C++ приложения как-то отцепиться от std::cin и подключиться к его свежей инстанции?

Откуда у тебя появится свежая инстанция stdin?

Пиши чего ты хочешь, а то нифига не понятно.

пасяб, попробую

А смысл с ним работать, если в нём ничего больше нет?

смысл в том, что echo «команда» | myap запустила бы и передала сразу же на её stdin команду

далее echo завершается, а моя прога оставалсь бы запущенной и по прежнему с живым stdin чтобы в него можно было отправлять комманды уже не через echo.

далее echo завершается, а моя прога оставалсь бы запущенной и по прежнему с живым stdin чтобы в него можно было отправлять комманды уже не через echo.

Оно так не работает. У каждого процесса есть один stdin. Он может быть подключён либо к терминалу либо к echo либое ещё к чему-то, но только к чему-то одному. Это что-то может писать к твоему процессу в stdin. Как это что-то кончится (терминал закрыли, echo кончился), то всё, некому больше в stdin тебе писать.

Можешь параметром передавать команду.

./myprog --сделать-хорошо

Или параметром передавать файл и брать команды оттуда.

Переоткройте stdin как /dev/tty, контролирующий терминал данного процесса, при помощи freopen. cin автоматически будет к нему привязан.

А ведь и правда ведь вся иделогия консольных пайпов передавать конвеерно инфу от одного к другому bin1|bin2|bin3 т.е. в данном случае нужно принять обработать, отдать и завершиться

Чем не устроили именованные пайпы (mkfifo)?

$ mkfifo cmdpipe
$ mybinary &
$ echo "cmd arg1 arg2" > cmdpipe
$ cat mycommands.txt > cmdpipe

Через них EOF не прилетает, что ли?

воу воу это круче чем у меня было

Через них EOF не прилетает, что ли?

Что мешает переоткрыть, в отличие от?
EOF - это тоже своебразный символ, который можно семантически нагрузить.

Кстати да, хорошая идея.

Было уже?

man popen?

Гуляла в интернете какая-то утилита. Которая переоткрывала пайп при получении EOF, а твоей программе EOF не передавала.

Нашёл http://okmij.org/ftp/Communications.html#sh-agents

EOF в mybinary прилетает, когда другая сторона закрывает свою сторону пайпа. Решение: не закрывать. Если это скрипт или интерактивный шелл, то пусть держит pipe открытым, пока echo в него пишет.:

$ exec {PIPEFD}> >(nl)
$ echo aaaaa  >&$PIPEFD
     1  aaaaa
$ echo bbbbb  >&$PIPEFD
     2  bbbbb
$ echo ccccccc  >&$PIPEFD
     3  ccccccc

видно, что nl не завершается и продолжает нумеровать строки.

Если перейти на более низкий уровень, то можно открыть одновременно на чтение и запись в неблокирующем режиме, тогда не будет прилетать EOF. Но в таком режиме несколько сложнее работать, и это не posix-совместимо.

Расскажи это авторам lsp.