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. :-)
LOL, I was hoping to quickly justify my needs to an end :)
But it's generally the best way: Find the
answer first, improve upon it second.
Generally, it's always my approach, but I'm sure as any other person
here, we've all had to deal with instances where this is but a lucky
circumstance. IANWNAPP (I am no where near a professional programmer).
There are few things that are 100% certain.
I was in a hurry when I wrote that, so just like many of the statistics
we hear from politicians or some organizations, it came quickly out of
the wrong spot.
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
Being honest, I don't know what I meant. I truthfully didn't have time
to read through the docs for all the comparisons (although I looked at
eval in particular: perldoc -f eval which didn't seem proper for my
specific execution issue (it dealt more with executing Perl code)).
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.
Wow, thank you for such a thoughtful and detailed explanation! I don't
think I've ever run across the $? before (forgive me if it was noted in
the ref, obj, mod book).
Personally, I cringe whenever I see `$command` or system "$command"
inside of anything I have to work on (albeit I have several scripts I've
done this in myself, and still use). Everyone has their own way of
coding, and someone's code always looks worse to someone else. After
all, we are all only learning, no matter what we know...right?
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
You are speaking of Unix (under shell) STDERR here, correct?
Your understanding and diligence in providing useful, specific and very
detailed responses amazes me. You get paid for this, right ;)
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....
The email thing was an example. I won't get into the drawbacks on
relying on SMTP as an error messaging protocol, as it's not documented
in any of the RFC's I've read ;)
100%, I'd rather not state where I got that figure. Given that I run a
network and do much of the automation programming, I'd like to restate
that number to perhaps something that any network op could agree upon
regarding reliability of perfection...
I think I'll check manually the next couple days for the success of my
system routines, then early next week take the time to get them Perl