From: Robert Klemme Date: 2009-08-10T21:47:50+09:00 Subject: Re: Calling another Ruby script 2009/8/10 Peter Bailey : > Robert Klemme wrote: >> 2009/8/10 Peter Bailey : >>> I have a lot of image processing scripts. Sometimes, rarely, they'll >>> simply fail because some of the images might be bad. But, I need to know >>> whether or not the images got processed or not. So, because an image >>> failure can literally lead to the whole Ruby script just failing, I'd >>> like to create a separate script that simply lists all of the files in >>> the input directory (separately from the processing script) and checks >>> to see if they all got processed or not. >> >> I am not sure I understand the requirement from this.  Why do you need >> a separate script?  What stops you from invoking a method in the same >> script that does the check? > This second script is the one that's doing the check. The first script > needs to process the images, meaning, it converts them to various other > formats. And, if the image processing fails (it's calling an outside > image processing utility), then, the whole Ruby script can simply fail, > too. What about preventing that? I mean, you could make sure that it does not stop processing even if the external program failed. You can even catch an exit as a quick hack: $ ruby19 -e 'begin; exit(12); rescue SystemExit => e; printf "tried exit(%i)\n", e.status; end' tried exit(12) $ echo $? 0 $ > If I have 50 files coming in, then, I'll need to know whether or > not those 50 files went to their proper destinations in their proper > formats. If the image processing fails for any reason, and the Ruby > script simply dies, too, then, I'll need to know that. But if the first script dies, there is no chance to invoke the second script from it. Or do you want to start the second script and have that call the first script? In any way I still do not see the need for two scripts unless your Ruby interpreter could actually crash. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/