input to a psuedoterminal
i have a psuedoterminal open in a terminal window (xfce4terminal to be exact). i want to stuff some input into it and have the shell on the slave side of the pty get it like any other typed input. everything was started under the same non-root user (there are no cross user issues). i see two possible ways, though there may be more. the 1st is that the terminal program may provide an interface to do this. the 2nd is writing directly to the master side of the psuedoterminal. i do have the tty device name from the tty command. how can i stuff type-in input into this psuedoterminal? i don't need to read the output though in the future that could be useful.
|
Without fully understanding what you wrote, I'm going to ask you one question:
Have you heard of expect? |
if I understand well it is a simple redirection:
command > /dev/pts/<tty> |
Quote:
Quote:
Which I interpreted as: Send text to the pty as though it was actually typed in at that pty and executed. "echo env > /dev/pts/NN" merely displays "env" on that pty, not display the environment on it. I suspect there's no easy way -- writing to another terminal's stdin via some command switch, etc., anyway -- to do this. Perhaps if the target pty was running some "odd" program instead of a normal shell? |
ah so. in that case something need to catch that "stdin" and execute.
You can [try to] execute bash using stdin as command input and use a socket. |
Quote:
if you know how to get expect to "connect" into an existing pty, please say where you read how to make it do that. |
under the old way of doing psuedoterminals there were separate tty and pty devices with matching numbers. this kind of thing was trivial: just write to the other device and was like typed input, though more than one character at a time would be too fast and could overflow some buffers. the more at once the worse the chances.
inserting a program in front of the shell could be plausible. but i would have to set that up to run the extra process all the time. but it might be doable to handle bulk strings better, like pacing them at a configurable speed. i usually run many shell terminals that just sit idle ready to be used. at this moment the total in use and idle is 98. for me this would mean adding 98 more process, though most would be idle. |
Sending a command to another terminal instead of executing it is pointless. You can execute it directly, the result will be exactly the same.
|
Skaperen, can you please rephrase and expand on what you are aiming to accomplish?
|
Quote:
the script doing the typing will be running the same effective userid as the terminal and shell so the ability to do this fake typing must not depend on having root or sudo privileges. at the time the terminal and shell are started, it is unknown which might need to be typed in to. there are many different userids and instances of X (usually more than 15) running with many (usually 10) virtual screens, st up. each userid has one instance of X but different virtual screens may be doing scrpted type-ins concurrently. this means a general type-in to the X server is not specific enough ... some terminals may not be displaying because they are in an inactive virtual screen. if i need to do mods to make this work, i would add an option to the terminal to add an interface (named unix socket on which the userid of the connecting process can be verified). this interface would provide a stream for input and a stream for output (what is to be rendered on the screen), as well as other features like access the graphical content, and controls like resizing the window, changing colors, and so on. a C program could make it easy for a script to connect. does that explain it enough? |
but why? What is the point? usually you need to run a server which can listen on some port/socket/whatever to accept external requests. A general interactive shell - which is running in a terminal - is different, it is waiting for input on its tty. The only way to feed some commands to bash is to redirect its stdin, like this:
Code:
cat shellscript | bash Additionally much easier to execute the command directly instead of sending it to another shell... The other way could be to rewrite the X server to be able to send keyboard events to windows/terminals/whatever which are not in focus or on screen. Or to write your own pty handler which can somehow accept events from another app, socket, whatever... |
Or maybe the task can be shoehorned into xterm and tmux instead:
Code:
DISPLAY=:0.0 xterm -x sh -c 'tmux new-session -s skaperen -n a_script \; \ |
Quote:
Just a thought... |
Quote:
Quote:
Quote:
well, tty emulation was reading it and there used to be an individual device that could be opened (by another process) to write there. BTDT. Quote:
Quote:
Quote:
Quote:
Quote:
who knows, maybe a means to do that has already been done. |
Quote:
|
All times are GMT -5. The time now is 06:12 PM. |