GNOME Bugzilla – Bug 310824
zenity --progress kills parent process!
Last modified: 2009-12-07 11:53:40 UTC
Version details: 2.10.0 Distribution/Version: Ubuntu 5.04 Basically in the following code if I am to cancel at the --file-selection dialog everything does cancel correctly. But if I am to cancel at the --progress dialog the commands I issue do not go through. myfile=$(zenity --file-selection --title="Create image from CD" --save --directory --filename=~/newimage.iso) if [ $? != 0 ]; then exit 0 fi ( echo "0"; sleep 1 dd if=/dev/cdrom of=$myfile bs=1024 echo "100"; sleep 1 ) | zenity --progress --pulsate if [ $? != 0 ]; then killall dd fi
After messing around a bit I came to the conclusion of being pretty certain this is a bug. I was just testing some commands in a terminal to see what they spit back as output. For instance 'zenity --question;echo $?' ... cancel returns 1 and okay returns 0, just like the documentation says. However ... try 'zenity --progress;echo $?' ... and you never get a chance to see what it's returning because it exits the terminal session. In my case this is a bad thing because I cannot include the appropriate commands to kill the process that --progress was relating to in the first place, nor can I remove the incomplete ISO.
Just an short explanation: the current behavior of Zenity Progress Dialog when you click on cancel button is killing the parent process and return an error code (1). Maybe It'd better to just return 1 and let the user choose the cancel behavior. Is that what you're suggesting?
Yes. :) Like in my case I cannot stop the dd process unless I am able to choose the cancel behavior. We could then even have the ability to prompt on cancel. Like as if they really want to cancel the action being taken ... if no just resume the --process dialog. :)
We'll make it on 2.13 because ATM zenity is feature-frozen.
Created attachment 56150 [details] [review] patch With this patch users will have to decide what to do when cancelling. Anyway, I think that an option like --progress-kill-in-cancel won't be bad at all, what do you think Lucas?
Created attachment 56151 [details] [review] oops Previous patch was mixed other patch. Sorry.
Created attachment 62224 [details] [review] patch to add --auto-kill to --progress dialogs.
I tried different combinations to capture anything from zenity but no success, namely ---- (zenity --progress ...) | sed 's/Hang/Hangup' read HUP_SIGNAL if [ "$HUP_SIGNAL" = "Hangup" ] kill something... fi ---- (zenity --progress ... & PID="$!" something... ) && kill $PID && kill something.... ---- zenity --progress .... && kill something.... these doesn't work, I'll try to see if there's something changed if I press the cancel button to compare my variable to.. joelbryan
*** Bug 337392 has been marked as a duplicate of this bug. ***
Fixed in HEAD! Thanks! 2006-12-02 Lucas Rocha <lucasr@gnome.org> * src/zenity.h, src/progress.c, src/option.c: add "auto-kill" option to progress dialog. Now the user can choose whether to kill parent process or not (Fixes bug #310824). Patch from Diego Escalante Urrelo <diego@aureal.com.pe>.
Zenity is sending a SIGHUP to the parent process when cancel is pressed. If you're forced to use an older version of Zenity where this behaviour isn't fixed. you can easely capture it using the trap command (at least when you're using bash). Example: trap 'echo "Cancel pressed!"' SIGHUP zenity --progress this can be used to easely clean up stuff when cancel is pressed. If you simply want to ignore the SIGHUP you can do something like that: trap '' SIGHUP zenity --progress I hope that helped, Florian