что лучше два пайпа или псевдотерминал???

c pty будет больше геморроя. если вам нужен только обмен
данными, имхо pipe. а еще лучше socketpair(AF_UNIX), раз
двунапрвленность нужна.

А через socketpair(AF_UNIX) я смогу прокачивать три потока??? Я хочу чтобы stderr & stdout не смешивались

ну можешь замутить простейший tlv протокол внутри этой сокетпары

> А через socketpair(AF_UNIX) я смогу прокачивать три потока???

не понял вопроса. перечитал первый пост, и тоже перестал
его понимать.

> stdin parent-a подключить к stdin child-a

что это, собственно, означает?

> не понял вопроса. перечитал первый пост, и тоже перестал его понимать.

он имеет ввиду как в ssh channeling сделан, тоесть в одном коннекте прокачивается несколько логических коннектов и по свитчу распихиваются в разные места

Извините за туманное обьяснение задачи. Попытаюсь чтото прояснить: Так вот некоторой проге нужно запустить другую прогу чтобы она выполнила некоторую операцию, а етой второй проге в процессе выполнения требуется немного пообщатся с пользователем на тему уточнения поставленного задания для чего ей нужен доступ к терминалу с которого была запущена родительская прога. Так вот вся проблема в том как ето реализовать. пока что я ничего лучшего не придумал чем тремя пайпами соединить stdin,stdout,stderr родительского и дочерних процессов.

> тремя пайпами

ого, их уже три!

> соединить stdin,stdout,stderr родительского и дочерних процессов.

вообще ничего не понимаю. как их можно соединить пайпом?
собственно, пайпом вообще ничего нельзя соединить.

и почему "ета прога которой нужно пообщаться" не может
просто и без затей использовать stdin? файлы наследуются
после exec.

потому что нам надо кудато возвращать результаты, для чего перед ехес делается fork() и при попытке вывести из child-процесса чё-либо на консоль(терминал) процесс получает SIGSTOP co всеми вытекающими последствиями.

> перед ехес делается fork() и при попытке вывести из
> child-процесса чё-либо на консоль(терминал) процесс
> получает SIGSTOP

~$ perl -we 'fork ? wait : exec "cat"'
123
123
456
456

не так все просто с job control. вы не задумаывались
о том, что ваша "основная" программа - это тоже exec()
после fork() которые сделал /bin/sh ?

еще раз, как вы собираетесь это решать с помощью pipe,
вот что мне совершенно непонятно.

Повесить select на stdin и на пайпы подключенные к stdout & stderr child-a. далее как в миникоме : разруливаем что и куда считаем нужным

> Повесить select на stdin и на пайпы подключенные
> к stdout & stderr child-a

так это же parent надо модифицировать! и это
parent будет общаться с пользователем через
терминал! 

посмотрите еще раз не пример с cat, который
я привел. не думаю, что вам нужен pty.

Обьясни почему в твоём примере child не получил SIGSTOP.

например у меня если в шеле какая нибуть фоновая прога захочет пообщатся с юзером то у меня она всегда получает и шелл выдаёт сообщение что прога ХХХ остановлена.

> если в шеле какая нибуть фоновая прога захочет пообщатся

потому, что _фоновая_, и tty->pgrp != process_group().
а fork() группу не меняет и в фоновый процесс не превращает.

~$ EEE perl -we 'fork ? wait : do { setpgrp 0,0; exec "cat" }'

вот так уже не сработает.

спасибо немного прояснил. Хотя ещё не всё ясно.

Пока. До завтра.

А что будет происходить если сделать так:

~$ EEE perl -we 'fork ? wait : do { POSIX::setpgid(0,0); exec "cat" }'

> ~$ EEE perl -we 'fork ? wait : do { POSIX::setpgid(0,0); exec "cat" }'

откуда эти EEE взялись?

не понимаю вопроса. что, POSIX::setpgid(0,0) означает
что-то отличное от setpgid 0,0 ? я никогда не пользовался
POSIX:: и смотреть не хочу.

> что-то отличное от setpgid 0,0 ?

пардон, зарапортовался, перепутал с setpgrp().
в linux perl setpgrp() и вызывает setpgid().
так что читать надо так:

что-то отличное от setpgrp 0,0 ?

>> ~$ EEE perl -we 'fork ? wait : do { POSIX::setpgid(0,0); exec "cat" }'

>откуда эти EEE взялись?

C твоего поста выше