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

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.
>=20
> I can not reproduce this using the command stated in the PR:
>=20
> $dialog --yesno foo -1 -1 </dev/null
>=20
> $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=20

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

--=20
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811

_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"