[tpm] IO::Handle not catching errors
linux at alteeve.com
Tue May 27 05:38:43 PDT 2008
Thanks for replying! I'll address your questions in-line. :)
James E Keenan wrote:
> On May 26, 2008, at 3:45 PM, Madison Kelly wrote:
>> I use IO::Handle for shell calls,
A couple years ago I was having trouble with some IPC stuff clobbering
"traditional" filehandles. I found that the 'Filehandle' module off CPAN
solved those problems. However, 'Filehandle' is not a core module, and
so expecting a user to have it could cause dependency problems. So I did
some looking and, perhaps incorrectly, realized that IO::Handle looked
to do the same thing and was a core module, so using it seemed to solved
the clobbering problem and not have the dependency problem.
Since then, I've made a habit of using it everywhere.
> When I call 'perldoc IO::Handle', among the first things I read is:
> "It is not intended that objects of "IO::Handle" would be created
> directly, but instead "IO::Handle" is inherited from by several other
> classes in the IO hierarchy."
> Your example does not suggest that you are inheriting from IO::Handle.
> Above and beyond that, you do not appear to be calling it in an
> object-oriented way. You create the IO::Handle object:
>> print " Shell call: [$shell_call]\n";
> ... and then proceed to use it as the second argument to a Perl built-
> in 'open' function, where one would normally expect something like '<':
>> open ($sc, $shell_call) or die "Shell call: [$shell_call] failed with
>> error: $!";
> On what basis do you expect the preceding statement to do something
This catch works... Say for example if the '$shell_call' had a bad path
to an executable, or if it lacked permissions, it would trigger 'die'
and properly exit.
> You don't appear to call a method on your IO::Handle object until here:
>> if ($sc->error)
>> die "Shell call: [$shell_call] returned an error: $!";
> I'm unclear as to what you're intending to do, but I suspect
> IO::Handle is not the way to do it. Can you clarify?
> Thank you very much.
> Jim Keenan
As I (probably incorrectly) understood the docs, the '$sc->error' should
be set if the called shell program ran properly but returned a non-zero
exit code (because something it was supposed to do didn't work).
In my current program, for example, I am calling 'rpm' to install a
package. The call the the 'rpm' binary works, so the first 'die' doesn't
trigger, but the 'rpm' binary itself exits with a non-zero code because
the RPM I was trying to install failed due to dependency issues. That is
was I want to trap.
More information about the toronto-pm