zenity --progress cancel button doesn't return a value

Bug #220656 reported by dpurple77 on 2008-04-22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
zenity (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

Binary package hint: zenity

On Gutsy with zenity 2.20.0-0ubuntu1 there is no code returned when the cancel button is clicked. There is an option --auto-kill that kills the parent process when used but that doesn't kill any child processes that may have started already and without the --auto-kill option nothing gets returned on the cancel button press so there is no way to handle the button press and kill the processes manually.

Example code :

mknod /tmp/pipe$$ p
        shntool split -f "$1" -o 'cust ext=mp3 lame --quiet - %f' -t "%n - %t" -d "$DirName" "$DirName/$FileName" \
        &> /tmp/pipe$$ | \
        (zenity --progress --pulsate --text="Splitting $FileName.\n Please wait until OK is active.") \
        < /tmp/pipe$$
        echo "$?"
rm /tmp/pipe$$

This code uses shntool to split an ape file based on its cue file which calls lame (for mp3 creation) and mac (for the ape file handling) as children processes. If the --auto-kill argument is used the program gets killed but the children processes lame and mac keep running. If not , cancel doesn't do anything at all. $? echoes 0 when everything is finished and ok is pressed.

Pedro Villavicencio (pedro) wrote :

thanks for your report, is this still an issue on hardy?

Changed in zenity:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
dpurple77 (dpurple77) wrote :

Yes it appears so.

bodhi.zazen (bodhi.zazen) wrote :

This looks like an old report, but I ran into the same type of issue.

I do not have a solution, but an ugly hack to test if zenity is running and if not kill the children processes.

That statement just looks wrong o.O

At any rate ...

Take a command foo ...

foo | zenity --progress --auto-kill & # Need to add an & at the end so the script continues.
while [ $RUNNING - eq 0 ]
 if [ -z "$(pidof zenity)" ] ; then
    pkill foo # You may need to kill -9 `pidof foo`

NOTE : this just kills the children precesses, you may also want to clean up after them (remove temp files ...)

Rudolf Adamkovic (salutis) wrote :

I can agree.

Cesare Tirabassi (norsetto) wrote :

This works for me on Intrepid. Anybody else can confirm or otherwise?

Pedro Villavicencio (pedro) wrote :

works also fine for me, marking this as fix released, thanks for reporting.

Changed in zenity:
status: Incomplete → Fix Released
Jean-Philippe Fleury (jpfle) wrote :


Say I have this script:

#! /bin/bash
cd $HOME
tar xvfz zzz.tar.gz | zenity --progress --pulsate --auto-close --auto-kill --title="Test" --text="Test"

If I click on the "Cancel" button of the progress bar, the tar command still runs. Only the parent script is closed, but not the children processes. I'm on Ubuntu 8.10.

Forlong (forlong) wrote :

I am reopening this, since it has not been fixed in the application itself.
I consider this a major flaw in zenity as there seems to be no proper way (I'm trying for hours) to work around this.

bodhi.zazen's workaround is – I'm sorry to say – actually pretty bad, since it consumes CPU for no reason at all with that loop.
Additionally killing EVERY instant of the respective process can not be considered a sensible solution.

What if the user has other instances running? Take wget for example: killing wget completely will terminate all downloads the user may have already running.

Changed in zenity:
status: Fix Released → Confirmed
Siegfried Gevatter (rainct) wrote :

Zenity should be returning an error code if the users presses Cancel on the progress dialogue.

   [autokill stuff... ]
   zen_data->exit_code = zenity_util_return_exit_code (ZENITY_CANCEL);

rumi (rumi-launchpad) wrote :

Try the solution without running in background and checking zenity is still working.

It seems echo command exits the loop when application reading the pipe is closed.

(while true; do
   echo `tail percentage_file`
   sleep 3;
done) | zenity --progress

Trick with echo resolves cancel button support.
Please confirm it works for you.


beefcurry (jonzwong) wrote :

this zenity bug is still present in Jaunty Release Candidate.

UnLuckyLuKE (zanchetta-luca) wrote :

Hi everybody, I had the same problem with my bash scripts, so I try to find out some solutions.
This is worked for me in Ubuntu Intrepid Ibex

my_app | (if `zenity --progress --auto-close --text='In progress' --title='In progress'`;
                     echo 'Job completed'
                     killall my_app

UnLuckyLuKE (zanchetta-luca) wrote :

Sorry, I just realized I pasted the rough copy... Please ignore my previous post.

Hi everybody, I experienced the same problem in my bash scripts, and I tried to find out a workaround. The following bash code worked for me in Ubuntu Intrepid Ibex:

foo | (if `zenity --progress --auto-close --text='In progress' --title='In progress'`;
                     echo 'Job completed'
                     killall `basename $0`

Hope this helps!

I don't know if this issue is solve but i have made a script using zenity progress fully functional.

The script makes a backup file. The progress bar also works fine, it shows the exact percentage of the copy and if you press the cancel button close the zenity window and kill the copy process. I hope this would help to someone.

Here's a copy of the code i wrote.



size="$(ls -l ~/.VirtualBox/XP.vdi | awk '{print $5}')"
cp $fuente $destino &
while [ $copy -lt $size ]
 sleep 1
 porcentaje="$( echo "scale = 5 ; $copy / $size * 100 " | bc )"
 echo "#Copiando $copy bytes. Tamaño total: $size bytes."
 echo $porcentaje
 copy="$(ls -l $destino | awk '{print $5}')"
done | zenity --progress --width=350 --title='Creando XP.vdi.backup'

if [ "$?" = 1 ] ; then
 pidC="$(pidof cp)"
 kill $pidC
 rm -v $destino
 zenity --info --width=300 height--200 --title="Borrar Backup" --text="El proceso numero $pidC ha sido destruido.\n\nEl archivo $destino ha sido borrado."

P.D. I'm from Mexico, thats why the labels and the variable's names are in spanish. Hope doesn't matter.

Pedro Villavicencio (pedro) wrote :

Could somebody send this upstream at bugzilla.gnome.org ? Thanks.

Changed in zenity (Ubuntu):
status: Confirmed → Triaged
Locke (locke-db) wrote :

The mentioned script kludges aren't always an acceptable method to workaround this problem. We need a patch to zenity to allow proper functionality. (return suitable error status when cancel button is used.)

Changed in zenity:
status: Unknown → Invalid
Changed in zenity:
importance: Unknown → Medium
cpcbegin (cpcbegin) wrote :

This error is still on Ubuntu 14.04 64 bit

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.