Re: Initiate command in another shell session?

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.

 

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.

But you
are redirecting output to the _local_ `/dev/pts/22` (again,
assuming you have write permissions to that device).  That is,
the `ssh` command is running on the same system where you are
writing to `/dev/pts/22`, and the `ssh` client command has its
standard output connected to that pty device; whatever runs on
"somehost" as a result of you running `ssh` is happening on that
system, as invoked by the SSH server, that has no knowledge of,
or interest in, how the client is configured with respect to its
IO configuration, let alone local ptys: that is, the distant
end, assuming that "somehost" is a distinct system other than
the one you're doing all of this on, has no access to the state
of the local pty devices on the source end.  Indeed, given
the way that you've run this, `ls` on "somehost" is likely not
assocaited with any terminal device at all.

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.

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

 
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.

[ SunOS stuff answered in previous post ]

Janis

[*] 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.