After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 540560 - "zenity --list" loses end of quickly piped input
"zenity --list" loses end of quickly piped input
Status: RESOLVED FIXED
Product: zenity
Classification: Core
Component: general
2.23.x
Other All
: Normal normal
: ---
Assigned To: Zenity Maintainers
Zenity Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-06-28 00:33 UTC by Matt McCutchen
Modified: 2014-06-09 16:08 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
fix handle_stdin (932 bytes, patch)
2010-11-17 11:39 UTC, Victor Ananjevsky
none Details | Review

Description Matt McCutchen 2008-06-28 00:33:37 UTC
Please describe the problem:
If a program quickly pipes a lot of input to "zenity --list" and then quits, zenity loses the end of the input.

Steps to reproduce:
1. for i in {1..10000}; do echo $i; done | zenity --list --column=Number
2. Scroll to the bottom of the list.


Actual results:
Most of the list entries are missing.  Often I get just entries 1 through 539.

Expected results:
All 10000 entries appear.

Does this happen every time?
Yes, for me.  However, the problem is timing dependent.  If you can't make it happen, try adding a sleep:
for i in {1..10000}; do echo $i; done | (sleep 1; zenity --list --column=Number)

Other information:
The problem appears to be that, when the program generating the list data exits, zenity_tree_handle_stdin gets G_IO_HUP on the pipe and stops reading, even though there is still data left in the pipe.  zenity should keep reading until it no longer gets G_IO_IN.
Comment 1 Matt McCutchen 2008-06-28 01:05:25 UTC
--progress has the same problem.  On my computer, the following command stops at "Processing item 444".

for i in {1..1000}; do echo "#Processing item $i"; done | zenity --progress
Comment 2 Matt McCutchen 2008-06-30 21:36:50 UTC
Attachment 113739 [details] includes a fix for this bug.
Comment 3 Victor Ananjevsky 2010-11-17 11:39:03 UTC
Created attachment 174671 [details] [review]
fix handle_stdin
Comment 4 Arx Cruz 2011-01-03 01:12:45 UTC
Thanks for the patch! It's already on master.
I've check here, and using both:

for i in {1..1000}; do echo "#Processing item $i"; done | zenity --progress
for i in {1..10000}; do echo $i; done | zenity --list --column=Number

It shows all th 1000 processing item x and list all 10000 lines in the list.
Comment 5 Jasper Lievisse Adriaanse 2011-06-27 08:09:27 UTC
The commit that fixed this issue, broke --auto-close support: https://bugzilla.gnome.org/show_bug.cgi?id=653468

As mentioned there, I think this commit should be reverted for now.
Comment 6 Steven W. Elling 2014-06-09 16:08:54 UTC
It appears this bug fix has been applied to a version of zenity that can only be used with GTK+3 and therefore does not help users experiencing the bug on system tied to GTK+2 (e.g. RHEL 6 & CentOS 6).

What is the likelihood of having this bug back-ported to a version of Zenity that is compatible with GTK+2 and a new release created from it?

Per the NEWS file:

* Zenity 2.91.1, "Make zenity compile only with GTK+-3.0 (Luis Medinas)"
* Zenity 2.91.5, "Fix for bug 540560. Patch by Victor Ananjevsky (Arx Cruz)"