I want a timeout that only kills a command for inactivity (seconds passing with
no output), and it really seems like a thing "timeout" should be able to do, and
it's not HARD to implement (pass the output data through a pipe, copy it to
stdout resetting the timer, and use poll() as the timeout mechanism instead of
timer_settime()).

That said, people grumble when I add new capabilities that the existing command
doesn't have, so I thought I'd give a heads up to see if anybody had strong
objections. (No, I am not having it be a --longopt-only; by that logic no short
option would ever be added again and unix command line is all about short 
options.)

Rob

P.S. Ok, technically I should do a pty instead of a pipe if output is to a
terminal, but I can't be bothered, -i mode would have that side effect. And it's
a little awkward having different coeepaths for -i and non -i in the same
command, but... eh? The non-i timeout code's already there, and xrun()/xpoll()
are already in lib/net.c so it's probably not much new...

P.P.S. The motivating case here is running "make tests" under mkroot, where the
qemu instance can take an arbitrarily long time to chug through a bunch of tests
(emulation is slow, I add more tests all the time, I dunno what underpowered
wind-up-toy somebody might run this on), but am comfortable saying that if it's
produced no output for 30 seconds it's hung and should be killed.
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to