gnu/137665: [patch] dialog(1) goes into tight loop on encountering eof

Stefan Bethke stb at lassitu.de
Sun Feb 27 21:29:39 UTC 2011


Am 27.02.2011 um 21:55 schrieb Eitan Adler:

>> dialog does not go into a tight loop eating all CPU, but it still gets stuck.  I believe it should take some action on encountering EOF, instead of waiting for input forever.  My patch did that for the old dialog, typically taking the same path as pressing ESC would.
> 
> I can not reproduce this using the command stated in the PR:
> 
> $dialog --yesno foo -1 -1 </dev/null
> 
> $dialog --version
> Version: 1.1-20100428

You are correct, I did assume that dialog was hung when in fact it is waiting for input.  The man page does not mention any behavior relative to stdin being redirected, and I expected dialog to honor a redirection.  Evidently, it manages to take input from the tty instead of from stdin.  Is this the expected behavior?

# printf "\n" | dialog --yesno foo -1 -1 

This will wait for input from the tty, instead of returning immediately.

The reason I'm unhappy with the behavior of the old dialog, and the current behavior, is that if a script unintentionally invokes dialog (for example when running portupgrade from a script, and the port or package using dialog), the script stalls.  If you run the script from a cron job, it will never terminate.  I'd prefer a deterministic, terminating reaction to stdin not being a tty.

While dialog is meant to provide a user interface, there are situations where you want to be able to script someone elses use of (some embedded) dialog, and I'd rather have a chance to at least continue instead of being stuck at that point, or even having to break out expect again.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811





More information about the freebsd-bugs mailing list