While really really bored, VaX#n8 wrote:
> So, on that note, I wrote another program which was a "master" and forked
> off a sub-process which should dial/connect/ping/whatever.  However, this
> "master" program simply configures the line (as clocal) and then opens it,
> but it hangs -every other time- on open. It doesn't get to the forking loop
> on the even-numbered runs.  Of course, if it works right, it should only
> run once, but what is holding state between sequential runs?

Most interesting results!
It appears that after the first run, the forked child which held the line
open did not get killed, and thus the second time the program was run,
the forked child did not block and simply exited, causing the stty to
have no effect... but that's not the good part.

I normally killed off the child process using "kill 16783" or whatever.
However, I noticed that TR {DTR, in RS-232 terms} was not going off!
A quick "ps -x" showed that the process was no longer with us.
However, if I typed "/bin/kill 16783" or whatever, using the system kill
instead of the BASH builtin, DTR -did- go off.
It appears that using the BASH kill puts the program in some kind of limbo
land where I cannot see it, but it can still hold the tty settings.

Is there some fundamental Unix Truth I am missing, or is this some kind
of bug in the kernel, ps, or BASH?

FWIW, BASH was compiled/installed on 22 Sept, while /bin/kill was made on
6 Sept.  I don't think my script is the problem, so I'm not posting it yet.
-- 
VaX#n8 (vak-sa-nate) - n, CS senior++ and Unix junkie - vax@ccwf.cc.utexas.edu
Just the vax-man.  Read my MIPS, no new VAXes!        - PGP key on request