Re: Most dependable way to run system commands
- From: tom@xxxxxxxxxxxxxx (Tom Phoenix)
- Date: Wed, 12 Dec 2007 19:53:57 -0800
On 12/12/07, Steve Bertrand <iaccounts@xxxxxxxxxx> wrote:
I am heavily modifying (re-writing) some Perl scripts that are bundled
within the dialup_admin web interface for FreeRADIUS.
Eventually I'd like to bring the execution of a few system commands
(executing mysql binary and importing an SQL file into it) into Perl,
however, for now I just need it to work.
Well, that's pragmatic. :-) But it's generally the best way: Find the
answer first, improve upon it second.
Essentially I don't have the time to rewrite that entire portion right
now, so I'd like to know the best way to execute the SQL system commands
and be 100% sure that it ran properly, and if not, I would be notified.
There are few things that are 100% certain. But let's see what we can do.
At this point, the command is done via backticks.
What I'd like to know is what would be the best way to quickly hack this
so that if it fails and neglects to insert every row, I could have the
app tell me (via email or whatever) so I don't have to do a manual check
every morning.
AFAICT, I've got the backtick option, system or eval.
You don't mean eval. You think you mean exec, but you don't mean that
either, probably.
Will system or eval be able to see that each row is inserted without
error when the mysql binary is called at system level? Or would it be
best if I just took the time now and did it with DBI immediately instead?
I think you're looking for the program's exit status. Traditionally on
Unix and many similar systems, the exit status is an integer, with 0
meaning "normal exit" and anything else meaning that something went
wrong. That's the value that's used by programs that run other
programs (such as the 'make' system utility) and need to know when a
step has failed. In Perl, you can access the exit status with the $?
variable after running a command via system or backticks. Beware: If
your command is run by the shell, you'll get the shell's exit status,
which may not be the exit status you were looking for.
You can also consider capturing the STDERR output of the external
program. Since the exit status doesn't say much, most programs cough
out some last words when something goes wrong. In fact, if the program
outputs anything to STDERR, even if it exited with "success", the
error text may be important news you'd want to treat as a failure. One
common way to capture STDERR when running an external program is with
IPC::Open3.
I must admit to a philosophical problem with the idea of a program
that sends email when something goes wrong. How, I ask myself, does
such a program report that it cannot send mail? That 100% is looking
more and more elusive....
Hope this helps!
--Tom Phoenix
Stonehenge Perl Training
.
- Follow-Ups:
- Re: Most dependable way to run system commands
- From: Steve Bertrand
- Re: Most dependable way to run system commands
- References:
- Most dependable way to run system commands
- From: Steve Bertrand
- Most dependable way to run system commands
- Prev by Date: install non-current version module from cpan shell
- Next by Date: Re: Not catching HUP signal - Perl Sybase
- Previous by thread: Most dependable way to run system commands
- Next by thread: Re: Most dependable way to run system commands
- Index(es):
Relevant Pages
|
