Re: Initiate command in another shell session?

Liste des GroupesRevenir à cu shell 
Sujet : Re: Initiate command in another shell session?
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.unix.shell
Date : 14. Mar 2025, 03:41:47
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vr051d$c5da$1@dont-email.me>
References : 1 2 3 4
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 13.03.2025 19:25, Dan Cross wrote:
In article <vqv1c0$3gq75$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
[...]
 
I think I understand; let me paraphrase, and tell me if I'm
correct?
 
[...paraphrase snipped...]

Yes, that was correct.

 
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 unformed thoughts went along the line of how a pty intercepts
communication to a process, probably combined with an attachment
to a process (as I recall you can attach a debugger to a running
process).

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

I'm pretty sure it wasn't the keyboard(s). (At least I see no way
how it should have influenced that extreme effect. Both keyboards
are firmly attached, they worked smoothly many years, and still
did their job after the system restarts.) It could of course have
been some OS component handling the keyboards in principle, but
all the above described accompanied effects that I observed are
also unrelated to the keyboard. So at best very unlikely I'd say.
Anyway. After the reboot everything was fine, so I don't make my
mind about it. It was just something I've never observed before;
typically, if anything, my window manager (or other long running
processes) show problems occasionally after long uptimes, while
the rest works smoothly, but this time... just strange (to me).

Janis


Date Sujet#  Auteur
13 Mar 25 * Initiate command in another shell session?17Janis Papanagnou
13 Mar 25 +* Re: Initiate command in another shell session?6Dan Cross
13 Mar 25 i+- [OT] SunOS issue (historic) (was Re: Initiate command in another shell session?)1Janis Papanagnou
13 Mar 25 i`* Re: Initiate command in another shell session?4Janis Papanagnou
13 Mar 25 i `* Re: Initiate command in another shell session?3Dan Cross
14 Mar 25 i  +- Re: Initiate command in another shell session?1Janis Papanagnou
16 Mar 25 i  `- Re: Initiate command in another shell session?1Jim Diamond
13 Mar 25 +- Re: Initiate command in another shell session?1Kaz Kylheku
13 Mar 25 +- Re: Initiate command in another shell session?1David W. Hodgins
13 Mar 25 +- Re: Initiate command in another shell session?1Christian Weisgerber
14 Mar 25 +* Re: Initiate command in another shell session?6Keith Thompson
14 Mar 25 i+- Re: Initiate command in another shell session?1Kaz Kylheku
14 Mar 25 i+- Re: Initiate command in another shell session?1Dan Cross
14 Mar 25 i`* Re: Initiate command in another shell session?3Christian Weisgerber
14 Mar 25 i `* Re: Initiate command in another shell session?2Kaz Kylheku
15 Mar 25 i  `- Re: Initiate command in another shell session?1Christian Weisgerber
14 Mar 25 `- Re: Initiate command in another shell session?1Janis Papanagnou

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal