Re: Initiate command in another shell session?

In article <vqv1c0$3gq75$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:

On 13.03.2025 14:01, Dan Cross wrote:

In article <vquhba$3817f$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:

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.

 
I don't think I understand what you mean.  Do you mean that you
would be able to hijack a user's TTY in order to run commands on
some other system (e.g., via `ssh` or something) as them?

>
Actually that question arose after a necessary reboot of my system,
which had shown a strange effect[*] and was unusable. - I wanted to
obtain from my shell sessions some information, and since I happen
to have dozens of shell windows open in parallel - and I considered
it boring to go through all virtual windows with all it's individual
shell windows - I thought about starting that request on each window
uniquely from one shell window. That's how it started why I pondered
about the question and tried a couple things.
>
So, no; no hijack intended, no other users concerned. (I'm the only
user on my system, or so I hope.) It was at that point actually an
academical question.

I think I understand; let me paraphrase, and tell me if I'm
correct?

I think you're asking if you can write to a terminal device, and
have what you write be treated as input data for whatever
program is running on that tty/pty; is that right?  And then, if
that is possible, whether you can do this over the network?

So that, for example, if you have a terminal emulator with a
window that is running some shell process, controlled by some
pty device, you could execute a command on that computer over
the network that would get the shell running in that window
run some command?

If that's correct, then the answer, generally is no: you can't
do that.  If you open the pty device associated with that shell,
you're and write to it, you're really writing to the same
output that the shell process is connected to, not it's input.

There's no simple way to interpose onto the input stream.

My first thought was that it might be an undesirable property (if only
for "security reasons", or more likely, generally).

 
Yeah, that seems bad.
 

What I can do is
[...]

 

Note that the latter will not operate in the shell context of the shell
session that is running on somehost with /dev/pts/22.

 
This is the part where I'm not sure what you mean.  You are
executing a command on "somehost"; in this case, `ls`.

>
I used the "somehost" just as describing the general case for using
these remote tools. In my case I actually used 127.0.0.1 (localhost)
for the test case I was interested in.
>
[snip]
>
I used 'ls' just as an example to show that the remotely executed
program needs shell context information from that remote terminal
since each shell window will reside in an own working directory.

Sure.  But it doesn't really change things, if what I wrote
above is correct vis understanding what you're getting at.

(Note: In my environment I actually can get that $PWD information
after a reboot because I have set it up to memorize that for each
shell window. But a shell session has yet more context, and, as
said, it was a principle academic question at that point whether
it was doable in the first place or prohibited or impossible by
other principle factors.)

Yeah.  Note that working directory is inherited through an exec.
So the terminal emulator, when it goes to run a shell, can
arrange to chdir into an arbitrary directory before in the
process it creates before it exec's the shell.  That's how that
part works.

If instead you had run:
 
    ssh somehost 'ls > /dev/pts/22'
 
Then you would be writing to `/dev/pts/22` on the distant end,
not locally.
 

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).

 
I'm still not sure what you're asking.

>
I hope it got clearer from the additional information.

If my understanding of what you're getting after above is
correct, then yes.

[ SunOS stuff answered in previous post ]

>
[*] Something I never noticed before, BTW. - My CPU% was at "0%",
not even the typical high basis load of Firefox was displayed. The
whole window manager stuff (mouse movement, menu item selection,
change of virtual sessions, switch to plain non-WM consoles, some
tools in the task-bar like the clock was still counting, etc.) was
working, though, but not a single (other) command got executed;
not even a new cursor shown when hitting <Enter> in a shell window.

Are you sure the issue wasn't with your keyboard?  I'd have
maybe tried to disconnect and reconnect it.

- Dan C.