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 <[email protected]> Fon +49 151 14070811 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
