Maybe these schema can clarify the situation.
This is the usual setting:
Terminal (/dev/ttyX or /dev/pts/x)
device
|
(screen)<--[<output]----x-------(stdout) Process1
Terminal (keyboard)---[input >]---o-\----->(stdin)
\ \
(hardware console or \ `----(stdout) Process2
virtual console or terminal `---->(stdin)
emulators like xterm, …)
And there is no way to plug some new Process3
like this:
Terminal
device
|
(screen)<---o---[<output]--x------(stdout) Process1
Terminal (keyboard)---/-x--[input >]-o-\---->(stdin)
| / \ \
| | \ `---(stdout) Process2
| | `--->(stdin)
| |
\ `---------------------(stdout) Process3
`--------------------->(stdin)
What screen (and others) does is allocating some pseudo terminal device (like xterm does) and redirect it to one or more "real" terminals (physical, virtual, or emulated):
Terminal pseudo
devices ,--> Terminal (/dev/pts/x)
| _______/ device
Terminal <--[<output]--- | | |
1 ---[input >]--> |screen | <--[<output]---x-----(stdout) Process1
|Process| ---[input >]--o-\--->(stdin)
Terminal <--[<output]--- | | \ \
2 ---[input >]--> |_______| \ `--(stdout) Process2
`-->(stdin)
Using screen -x
you can attach one more terminal, xterm, whatever (say Terminal 3
) to the screen session.
So no, you can't communicate directly through stdin/stdout with processes attached to a different terminal. You can only do so through the process that is controlling this terminal if it happens to be a pseudo terminal, and if this process was concieved to do so (like screen is).