On Sun, 16 Jan 2022, Christos Zoulas wrote:
screen -S ses -d -m -p 0 cat
screen -S sys -X quit
The 2nd session name should be `ses' shouldn't it?
I can't reproduce this...
Gah! now I can (with the old screen from the binary pkgs) and my "fix"
doesn't work anymore. Dunno what changed.
I can't reproduce this... Trying the following works:
christos
screen -S ses -d -m -p 0 cat
screen -S sys -X quit
> On Jan 4, 2022, at 6:45 AM, RVP wrote:
>
> On Mon, 3 Jan 2022, Christos Zoulas wrote:
>
>> Yes, in the end screen was at fault for setting CLOCAL in the pty which
>>
On Tue, 4 Jan 2022, Christos Zoulas wrote:
Isn't t_rawcv used only during the open? (t_rawcvf is used in write,
and t_outcvf is used in read).
I figured it as `t_rawcv':
In the slave:
tty_pty.c:ptsread() calls ttread():
479 } else if (tp->t_oproc)
480 error
In article ,
RVP wrote:
>On Mon, 3 Jan 2022, Christos Zoulas wrote:
>
>> Yes, in the end screen was at fault for setting CLOCAL in the pty which
>> prevented from SIGHUP from being sent. I fixed it.
>>
>
>I think the problem may be that in canonical mode, the slave goes to
>sleep waiting for
On Mon, 3 Jan 2022, Christos Zoulas wrote:
Yes, in the end screen was at fault for setting CLOCAL in the pty which
prevented from SIGHUP from being sent. I fixed it.
I think the problem may be that in canonical mode, the slave goes to
sleep waiting for input (in tty.c:ttread()) and nothing
In article ,
Valery Ushakov wrote:
>On Sat, Jan 01, 2022 at 21:49:00 +, RVP wrote:
>
>> OK, but, I think we can do better than rudely sending processes a SIGHUP.
>> Using the BSD-native /dev/ptm device (via openpty(3) & friends) instead of
>> /dev/ptmx seems to do the right thing: EOF when
u...@stderr.spb.ru (Valery Ushakov) writes:
>Solaris docs for (STREAMS-based) ptys say:
> When the master device is closed, an M_HANGUP message is sent to the
> slave device to render the device unusable. The process on the slave
> side gets the errno ENXIO when attempting to write on that
On Sun, 2 Jan 2022, Valery Ushakov wrote:
Why pkg? This is a kernel bug.
Best guess on my part: I wasn't sure if ptmx was a full-fledged NetBSD
citizen since libc uses /dev/ptm internally (only posix_openpt(3) opens
ptmx).
Category kern is fine with me; but, then, the fix is above my pay
On Sat, Jan 01, 2022 at 21:49:00 +, RVP wrote:
> OK, but, I think we can do better than rudely sending processes a SIGHUP.
> Using the BSD-native /dev/ptm device (via openpty(3) & friends) instead of
> /dev/ptmx seems to do the right thing: EOF when the PTY master is closed.
>
> File a PR
On Sat, 1 Jan 2022, Adam Russell wrote:
I can confirm that the patch given above works for me. I built this in
pkgsrc. After the existing patches ran I manually applied the patch and then
ran make.
OK, but, I think we can do better than rudely sending processes a SIGHUP.
Using the
Adam Russell wrote:
RVP wrote:
On Fri, 31 Dec 2021, RVP wrote:
OP: Try this patch:
---START---
diff -u screen-4.8.0{.orig,}/screen.c --- screen-4.8.0.orig/screen.c
2020-02-05 20:09:38.0 +
+++ screen-4.8.0/screen.c 2021-12-31 01:56:30.470670972 +
@@ -1801,6 +1801,10 @@
RVP wrote:
On Fri, 31 Dec 2021, RVP wrote:
OP: Try this patch:
---START---
diff -u screen-4.8.0{.orig,}/screen.c --- screen-4.8.0.orig/screen.c
2020-02-05 20:09:38.0 +
+++ screen-4.8.0/screen.c 2021-12-31 01:56:30.470670972 +
@@ -1801,6 +1801,10 @@
struct win *p =
On Fri, 31 Dec 2021, RVP wrote:
OP: Try this patch:
---START---
diff -u screen-4.8.0{.orig,}/screen.c --- screen-4.8.0.orig/screen.c
2020-02-05 20:09:38.0 +
+++ screen-4.8.0/screen.c 2021-12-31 01:56:30.470670972 +
@@ -1801,6 +1801,10 @@
struct win *p = windows;
On Fri, Dec 31, 2021 at 02:08:02 +, RVP wrote:
> On Fri, 31 Dec 2021, Valery Ushakov wrote:
>
> > I think screen is racing against the child process in MakeWindow.
>
> I think something else might also be going on:
Ouch. That probably also explains why I was getting corrupt
ktrace.out
On Fri, 31 Dec 2021, Valery Ushakov wrote:
I think screen is racing against the child process in MakeWindow.
I think something else might also be going on:
On NetBSD 9.2_STABLE:
$ screen -S ses -d -m -p 0 sh # create
$ ps -Au# check for screen & sh
On Fri, Dec 31, 2021 at 03:18:08 +0300, Valery Ushakov wrote:
> I think screen is racing against the child process in MakeWindow.
I filed https://savannah.gnu.org/bugs/index.php?61749 for this.
-uwe
On Thu, Dec 30, 2021 at 06:55:24 +0300, Valery Ushakov wrote:
> Building screeen with debugging shows that succesful session start has
> for the first read from the window:
>
> + hit ev fd 5 type 1!
> going to read from window fd 5
> -> 5 bytes
>
> but failed attempt has
>
>
On Wed, Dec 29, 2021 at 13:40:31 -0500, Adam Russell wrote:
> What I am finding is that works to some extent, but then that second session
> seems to quickly end.
>
> Here I start a session, list all sessions, quit all sessions, sleep for 10
> seconds, start a new session, list all sessions,
I have tried to reproduce what I believe are your findings, that some
delay before starting the second session is enough to fix things.
What I am finding is that works to some extent, but then that second
session seems to quickly end.
Here I start a session, list all sessions, quit all
On Wed, Dec 29, 2021 at 00:01:38 -0500, Adam Russell wrote:
> This is what I see
>
> -bash-5.1$ /usr/pkg/bin/screen -S some-session -p 0 -m -d
> -bash-5.1$ screen -X quit
> -bash-5.1$ /usr/pkg/bin/screen -S some-session -p 0 -m -d
> -bash-5.1$ screen -X quit
> No screen session found.
I was
20 matches
Mail list logo
