>> 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 > either, probably. 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 > IPC::Open3. 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... Thanks Tom, 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 lexical-ized. Steve -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
