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>

Unless I'm totally misunderstanding the description in #1, that doesn't meet the requirement of:
(Emphasis mine)

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.

yes i have. and i have even used it, before. have you? have you read its man page? expect creates its own pty to provide a controlling tty to the process it is starting. my goal is to "insert" into an existing pty that is controlling an existing shell to provide some type-in.

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?

i have many already created, running, and used, terminal windows with a controlled shell (usually bash, but not always). at rare times, i want to run a script in the background that "types" into that window. it should appear that what the script "typed" in was typed in through the human interface by a human.

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:
In this case you need to keep stdin open and that also means you have a server listening on a socket and not an interactive shell.
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:

That would launch a terminal with a multiplexed session within it and within that an instance of ping. It is shown using xterm but any other terminal emulator can be used. Some terminal emulators have a lot of options, as does tmux.

I'm thinking that cssh(1) sounds like it'd work except it creates new terminal windows. Perhaps taking a look at the source for that utility would generate ideas.

Just a thought...

do i have to answer that?

or that?

i used to not need to.
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.

and ready to handle various signals.

the idea is to do this on a shell that is already running with input from the terminal and will continue to run after the stuffed input is given, reading from that same terminal.

that is a whole separate and new instance of a shell, not the specific existing one that is the target for this stuffed input.

it's not necessarily a complete command. it may be partial input of a command. or it may be input to the command it does. it may also be internal shell commands.

or rewrite the terminal emulator application to do similar. to X the terminal is just another app. or rewrite QEMU to ... well, no

who knows, maybe a means to do that has already been done.

or maybe it has already been done.