Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.unix.shell
Subject: Re: Initiate command in another shell session?
Date: Thu, 13 Mar 2025 16:20:04 -0700
Organization: None to speak of
Lines: 73
Message-ID: <87plikjz6j.fsf@nosuchdomain.example.com>
References: <vquhba$3817f$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Mar 2025 00:20:09 +0100 (CET)
Injection-Info: dont-email.me; posting-host="bbf3b2da6e551caad2cd296cab2812d3";
	logging-data="118660"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/g5H9WGQoJ4r0M6BSVmeJO"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:JtB7l70UFAvAprz5DWdxWpQXhrs=
	sha1:AsSdd68HeUY5Mm3HE1IWe8OCfC8=
Bytes: 4099

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> The question occurred to me whether it would be possible to remotely
> execute a command as if started from another shell session *in* that
> shell session.
>
> My first thought was that it might be an undesirable property (if only
> for "security reasons", or more likely, generally).
>
> What I can do is
> * sending some data to another shell session, say,
>     ls > /dev/pts/22
> * get the output of a command executed on another host, say,
>     ssh somehost ls
> * send the output of a remote execution to another shell, say,
>     ssh somehost ls > /dev/pts/22
>
> Note that the latter will not operate in the shell context of the shell
> session that is running on somehost with /dev/pts/22.
>
> I guess the answer to my question is simply "no", but I'd like to have
> a confirmation (and possibly more specific rationales or remarks).
>
> Janis
>
> PS: On an old SunOS 4 SPARC system I was (without privileges) able to
> even change the remote users system characteristics (like mouse speed),
> but I suppose that must be considered a security issue on that platform.

Writing to a tty is easy, if you have the right permissions.
Pushing text input into a tty so it behaves as if it had been typed
is trickier, and not necessarily possible

On some systems, opening a tty and calling ioctl(fd, TIOCSTI, ptr),
where ptr is a char*, will cause the single character *p to appear
as if it had been typed.  This might not work for a tty other than
the current stdin, and it's started requiring root access in recent
Ubuntu releases.

At a previous job several decades ago, we had a command `typein`
that used this mechanism.  In most cases, I've found `eval` to be
a cleaner way to do what I was using `typein` for.

Emacs uses this mechanism for the `suspend-emacs` function:

    (suspend-emacs &optional STUFFSTRING)
    ...
    If optional arg STUFFSTRING is non-nil, its characters are stuffed
    to be read as terminal input by Emacs’s parent, after suspension.
    ...
    On some operating systems, stuffing characters into terminal input
    buffer requires special privileges or is not supported at all.  On
    such systems, calling this function with non-nil STUFFSTRING might
    either signal an error or silently fail to stuff the characters.

You can do this with tmux, which allocated and controls a pty for each
window.  For example:

    echo echo hello world | tmux load-buffer -
    tmux paste-buffer -t 1

This causes the pane named "1" to act as if you had typed "echo
hello world" into it.  You can use a named buffer ("-b TEMP") if
you don't want to step on the default one, and delete the buffer if
you don't want to keep the text (I sometimes use this for passwords).

Of course if the target pane doesn't happen to be sitting at a shell
prompt, odd things can happen.

I don't know whether GNU screen has a similar feature.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */