weird behaviour with os

[Go Phone]

Hello,

Just want to check if this behaviour is/was observed by others.

At the shell prompt,

% os pwd Enter

/usr/homedir

% pwd Enter # nothing happens until I press another Enter

After pressing the second Enter, I get the pwd output and also an empty prompt.

This only happens for the command after the os command.

Thanks

[da...@boddie.org.uk]

I don't see this behaviour. Running pwd after the os command works as expected.

I'm using 64-bit Linux. Which OS are you using?

[Go Phone]

On Tuesday, July 6, 2021 at 2:03:16 PM UTC-7 da...@boddie.org.uk wrote:

I don't see this behaviour. Running pwd after the os command works as expected.

I'm using 64-bit Linux. Which OS are you using?

Thanks for checking up on it.

I am using OpenBSD amd64. But, I am using the 64 bits version of dis. So, could be something messed up in the translation.

Thanks again

[Go Phone]

I am noticing this behaviour:

When the os command starts, it starts a reader process on stdin. This channel is added by wm/sh.b into a list of channels reading on the /dev/cons.pid (rdreq: list of file.read channels). The /dev/cons.pid is the stdin of the os reader process.

When the os process dies, it kills the stdin reader process. But, the channel still remains in the wm/sh list of channels reading on the /dev/cons.pid file. I do not see any explicit cleanup by wm/sh of such channels (in the rdreq list of channels). The only cleanup that is happening is when we send something into that channel and the send fails.

This is the reason for the need to press Enter twice so that send to the first channel fails and the data is sent to the newer or later file.read channel.

The wm/sh's sendinput function can use a loop to send to the next channel in the list of channels reading on the file.read of /dev/cons.pid when the send to a channel fails.

But, I cannot figure out why others do not notice this behaviour. And, that makes me suspect that I might have messed up something in the dis.64 port.

[Go Phone]

This fixes the issue on my machine. But, I am not sure if it is the proper solution. The emu console still has the message "csendalt failed" which makes sense as sending on to a channel failed.

diff --git a/appl/wm/sh.b b/appl/wm/sh.b

index 8f634329..56fd9766 100644
--- a/appl/wm/sh.b
+++ b/appl/wm/sh.b
@@ -752,9 +752,13 @@ sendinput(t: ref Tk->Toplevel)
                r.rc <-= (nil, nil) =>
                        ;
                * =>
+                       if(len rdreq > 0)
+                               sendinput(t);
                        return;
                }
        * =>
+               if(len rdreq > 0)
+                       sendinput(t);
                return; # requester has disappeared; ignore his request and try another
        }
        if(rawon)

[da...@boddie.org.uk]

Just so anyone else reading this is up-to-date, I mentioned on Discord that I also saw the same problem when using wm/sh to run os on a 386 build running on a 64-bit AMD system. So I think it's unlikely that you have messed up anything. :-)

I looked at some of the articles at http://ipn.caerwyn.com/ for any comments about os that might indicate that the problem was already known, but I didn't find anything.

[Valery Ushakov]

Yes, I see this on both NetBSD and Linux (64-bit host, 32-bit inferno).