Help me exit my script w/o leaving an orphan process running
Hello:
It's called TextRipper and it creates indexable and editable text files from any image. Feel free to copy TextRipper; it's licenced under GPL. My troubles are with cracking passworded pdf's. (As you can see, I meant any when I said any image.) I can't find a way for the user to cancel the decryption process by exiting the script without pdfcrack orphaning. Line 349 works the rest of the time; the concerned process is line 228. I believe it's a piping/subshell problem. At least that's how I've been going at it in vain. It's long but if you can help me you're probably going to need it all. Please note that I've made portability a priority and that the comments still require updating. Thanks for your help. Code:
#!/bin/sh |
So the first problem I have is that the script only has 347 lines each time I copy it and 228 puts me on a blank line :(
Would you be able to tell / highlight the code parts you are having issue with? |
precision
Grail:
thanks for looking into this. The process being orphaned if the script is exited: Code:
PDF_CPW=`pdfcrack -q --maxpw=$PW_LEN --charset="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 @#&'()*-_?,.;:+=%$" -f "$DN_FILE"/"$BN_FILE" | sed -e "s/'//g" -e 's/found //g' -e 's/user-password: //g' -e 's/owner-password: //g'`;; Code:
) | Xdialog --wrap --title "Rippin text" --gauge "TextRipper is processing... $ALL_FILES\n\n\n dave |
Well I agree that it appears to be some kind of subshell issue (seeing there are many within the code).
Just to confirm, you are saying that all other tasks that can be done within the main subshell (handled by Xdialog wrapper above) are able to be terminated successfully when the cancel option is chosen? I ask as I am not sure that closing the subshell would by default close anything running within it, but is more likely to orphan the process ( as you have found ) until it has completed or is killed. |
The thing is, pdfcrack is the only process that works for such a long time. Ie: convert will just do its thing or exit with error and that's all, so if you hit cancel even if it gets orphaned it's just a matter of seconds. But pdfcrack, unless it is killed, which i can't successfully code, just keeps on going and this can be a matter of days.
|
So then the real issue is finding a way to best kill this orphaned item.
Are there no related PIDs? I would have thought the script PID would be the parent or grandparent of this line of code?? So if you sift through ps you should be able to come up with an easy way to kill it or maybe even trap the cancel to kill it. |
Okay I think now were getting somewhere. I can't trap and I can't kill pid of because the script waits for pdfcrack to terminate before executing the next command. At this point, it seems that the logical solution would be to background the process, but i can't get this to work because wait doesn't do its thing. IOW if I bg pdfcrack, the script then just continues without waiting for the cracked password.
|
Quote:
the program continues unabated. Our issue is that we ourselves have terminated the script as a whole by clicking / selecting cancel which we know will still allow pdfcrack run until completion but we would like it to all stop at the same time. Therefore, add to the script that only when selecting cancel that you check prior to completion of main script for any other child PID related to it and then kill them as they should not be running once script has completed. |
Quote:
Quote:
Could you give me a simple working example, or perhaps an example applied to the T-Rip script?" Thanks again, Grail. |
Well I am not overly familiar with Xdialog, but I am guessing that you have some buttons available to you via this mechanism, one of
which is a cancel button (which I gleaned from where you wrote 'And the global progress window that should allow a script exit at anytime') I would also surmise that depending on which buttons are pressed that Xdialog alters its exit status (or maybe you can even program the exit status depending on the button selected). So where you have: Code:
if [ "$?" = 255 ] ; then for pdfcrack and kill that sucker :) Also, if I may suggest, when interacting with numbers you should use the appropriate tests as opposed to forcing it to be a string comparison. Code:
# if sh is only option then |
Quote:
Remember that I wrote: "... pdfcrack is the only process that works for such a long time. Ie: convert will just do its thing or exit with error and that's all, so if you hit cancel even if it gets orphaned it's just a matter of seconds. But pdfcrack, unless it is killed, which i can't successfully code, just keeps on going and this can be a matter of days." |
Ok ... I think I am following. So if I were to have the Xdialog screen in front of me and press the cancel button I will still wait for pdfcrack to complete ... correct?
Assuming this is the case, maybe you should place it in the background and continually check if its pid is still running and only continue when completed. This way you could also build in the cancel option so that the loop checking the pid would then also check either for the pid of the main program is still running or that the cancel button has been pressed. What do you think? Pseudo code: while cancel button has not been pressed and pid of pdfcrack is still available wait for ~30 seconds (time is up to you of course) |
I would suggest using pkill:
Code:
pkill -g $$ |
Okay Grail I'm going to try to apply your input as soon as I find the time. I agree with your reasoning, let's see if I can make it work.
Ntubsky, pkill -g $$ is a definite exit but if the script hangs while waiting for a subshell to terminate I can't call it. It is this work around that I'm looking for. |
Quote:
Grail's suggestion will probably work, but I'll suggest a non busy wait solution. Here's an abstracted example (I use zenity because Debian dropped Xdialog): Code:
#!/bin/sh |
All times are GMT -5. The time now is 02:53 AM. |