Re: info/t/dir-dangling-entry.sh hang on netbsd

[Gavin Smith]

On 2 June 2015 at 01:15, Karl Berry <address@hidden> wrote:
> It sounds like a good approach, but sadly, I get the same D hang on
> netbsd after the patch.  (I don't know yet if using mkfifo helps, but
> I'm not especially hopeful.)

I managed to get qemu set up with the NetBSD pretest image.
Unfortunately my processor ("Celeron 900") doesn't appear to support
virtualization so it is very slow to build. I managed to compile the
texinfo-5.9.92 pretest and ran the dir-dangling-entry.sh test and it
hung - C-c didn't work. In my attempts to get back to the shell prompt
I accidentally quit qemu all together and lost the built texinfo
pretest. Maybe I'll try again tomorrow.

I can still play around at the command-line. I found that "mkfifo
fifo" followed by "sleep 1 >fifo &" hangs the same way (this is on a
newly started image).

Quitting qemu, and starting it once more, I've tried "mkfifo fifo" and
"(sleep 1 >fifo) &". This behaves much nicer:

NetBSD 6.1.4 (GENERIC)

Welcome to NetBSD!

$ mkfifo fifo
$ (sleep 1 >fifo ) &
$ jobs
[1] + Running                 (sleep 1 >fifo)
$ ps
PID TTY   STAT    TIME COMMAND
443 tty00 S    0:00.25 -sh
453 tty00 I    0:00.00 -sh
465 tty00 O+   0:00.03 ps
473 tty00 I    0:00.01 -sh
$ sleep 1 <fifo
[1]   Done                    (sleep 1 >fifo)
$

So I suspect the difference is in the way that the NetBSD shell
redirects file descriptors for background processes. I expect that on
the other systems the shell forks and then redirects the file
descriptors, but presumably on NetBSD there is some kind of
redirection before the fork.

Here's an updated patch with the pseudotty invocation in brackets. In
general it may be the case that whenever a FIFO is opened by a
background process, when the other end of the FIFO is to be opened
later, this should be done in a subshell.

pass-fifo-to-pseudotty-2.diff
Description: Text document