From: Karel Zak <kzak@redhat.com>
To: Dyweni - Util-Linux <DDh8rwTFp32E@dyweni.com>
Cc: util-linux@vger.kernel.org
Subject: Re: Unexpected interaction between script and screen
Date: Tue, 14 Nov 2023 10:17:10 +0100 [thread overview]
Message-ID: <20231114091710.6kykaxqamd6tb34w@ws.net.home> (raw)
In-Reply-To: <7a796ba6caa03ceca594dec9add67fe8@dyweni.com>
Hi Dyweni,
sorry for delay.
On Mon, Nov 06, 2023 at 06:01:55PM -0600, Dyweni - Util-Linux wrote:
> Is there any idea on resolving this issue? What would be the best
> way to prevent a session running inside screen from being
> unexpectedly ended by script when the ssh connection to the server
> is lost?
>
> I'd like to find the best approach before coding a solution. The
> ideas I've had include:
> * simply skipping sending the EOF to the child
> * killing the child
It uses EOF to emulate on the internal terminal how pipes work for
example:
echo "ps" | script
We must send to the shell "ps" string and EOF and then *wait* for the
shell to exit correctly. If we send SIGTERM without EOF and without
waiting for shell termination, we will probably lose some output from
the shell. It's because script(1) is faster than shell.
But I can imagine that in some cases is this way unnecessary and just
send a signal is good enough.
So, add a new option to skip EOF and leave the main loop in
ul_pty_proxy_master() and sending SIGTERM to the child may be a good idea.
Send patch ;-)
BTW, it would be nice to have the log from:
SCRIPT_DEBUG=all script 2> log
to see your session in details.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
prev parent reply other threads:[~2023-11-14 9:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 21:16 Unexpected interaction between script and screen Dyweni - Util-Linux
2023-11-07 0:01 ` Dyweni - Util-Linux
2023-11-14 9:17 ` Karel Zak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231114091710.6kykaxqamd6tb34w@ws.net.home \
--to=kzak@redhat.com \
--cc=DDh8rwTFp32E@dyweni.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).