My current setup involves a kernel hack (patch) I wrote that creates an ioctl() call, and a program that calls which can be run from a shell script ... which logs in to a text console TTY, runs screen, and runs the (often interactive) program within screen in the shell screen started. This works well so far.

I'm moving away from using text console and would also like to deprecate the kernel hack (though if someone still wants it, they are welcome to have it). So I'm looking for a way to start screen to do this directly. It has to start things detached. The script that feeds input will exit when the input is done (so this is NOT a script that replaces the shell being run inside screen's session). The commands fed to that session will run one or more programs through a shell and usually leaving the programs running. I should be able to attach a screen client to that session, kill the program with Cntrl-C, get the shell prompt, and do whatever I want there. Again, this is NOT a script to be run inside the session, but rather, one that provides keystroke input to that session, much like an expect script (although at present I don't need to do any handling of the output to decide on inputs, so I don't need to run expect).

Anyone know how to do this in screen? The script that starts it (usually at system boot time) won't know which PTY is allocated, so it can't just open the PTY end and stuff inputs there.

If I'm reading this correctly, you're trying to accomplish two things:

1) Identify the pty used by the screen session.
2) Send arbitrary cli input to the session programmatically.
3) Be able to attach to that session at will and get to a CLI, meaning that the session is the script on top of a normal shell (bash or whatever).

Is that summary correct?


--jesse