Hello.
I am sorry to be here again, and it rather is a question than
a bug report. But i thought .. better than not.
On the dash list a FreeBSD programmer reported some problem with
the monitor mode of dash (it turned out a FreeBSD /bin/sh commit
from 2014, ([cd60e2c67d52, sh: Allow enabling job control without
a tty in non-interactive mode.) is not in dash yet), and my
thinking was Wheeler and "any problem can be solved with yet
another indirection".
So he then came back to me stating that yet-another-indirection
does not work because the "set -m" is not honoured in subshells
unless active in the main one, that is, PGID remains the same,
which is another "bug" in dash (and busybox ash, and likely also
FreeBSD /bin/sh if i got that right, .. it works in bash) but
process groups is what he needs. The only solution would be
starting another shell and then doing things vi -c.
So that changed the test to
#!/bin/bash
#!/bin/dash
#!/sbin/busybox.static sh
(
#/sbin/busybox.static sh -c '
#/bin/dash -c '
/bin/bash -c '
trap "echo >&2 outer sig" HUP INT QUIT TERM TTOU
set -m
(sleep 1) &
i=$!
set +m
#^ pre-wait is ok
echo >&2 "inner Main shell has: $(ps -o pid,pgid $$)"
echo >&2 "inner Sub-shell has: $(ps -o pid,pgid $i)"
wait $i
#set +m
#^ (post-wait is bogus either way)
echo >&2 inner goinghome
'</dev/null >/dev/null &
echo "Main shell has: $(ps -o pid,pgid $$)"
) #</dev/null >/dev/null &
echo "outer Main shell has: $(ps -o pid,pgid $$)"
Now i first did not reset "set -m" via "set +m" at all (which
would be ok in bash with a simple () redirection), causing the
bash that drives this (tmux-paned) terminal session to close.
That i did not understand.
It turns out that the inner shell tries to set the process group
(to the parent shell which no longer exists), then causing the
interactive bash on the terminal to read an EOF next, and without
ignoreeof set the interactive shell then exits. (This happens
also when "set +m" is called after the wait ie when parent is gone
already. .. I have never really looked what shells do, and when.)
Now i have no idea and have not looked, maybe some Linux or
FreeBSD specific "reaper" has to be set to overcome this, ie to
make the interactive bash instance the "super process" for the
process group of the child in order to avoid reading EOF (or
classifying it right).
It was just an observation that took me over an hour to
understand, and that i wanted to report.
Ciao,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
