Re: exec, system, or backticks
by deibyz (Hermit) on Oct 20, 2004 at 15:57 UTC
|
I think backticks are better when you need to capture the output of the process. If you're throwing away that value, maybe system will be more appropiate.
Updated:
From perldoc -f system:
You can check all the failure possibilities by inspecti
+ng $?
like this:
if ($? == -1) {
print "failed to execute: $!\n";
}
elsif ($? & 127) {
printf "child died with signal %d, %s coredump\
+n",
($? & 127), ($? & 128) ? ’with’ : ’without
+’;
}
else {
printf "child exited with value %d\n", $? >> 8;
}
I see you are not using the return value (system) nor the output (backtick). I recommend you to use system and allways check the return value of the process. | [reply] [d/l] [select] |
|
|
Thank you for your input!
| [reply] |
Re: exec, system, or backticks
by ikegami (Patriarch) on Oct 20, 2004 at 16:42 UTC
|
`$swbt_dms $item > $log/$key`;
$key = ...read file $log/$key...
Then you could simply do:
$key = `$swbt_dms $item`;
Otherwise, it's a waste to use `` when you discard the return value::
$key = system("$swbt_dms $item");
In Windows, you could also use Win32::Process and call $process->Wait().
exec is not appropriate since it doesn't return.
fork+exec, IPC::Open2, IPC::Open3, system 1, (Win32) and Win32::Process without $process->Wait() (Win32) are not appropriate since they create a process that runs in parallel.
| [reply] [d/l] [select] |
|
|
I need to capture the output from the Expect script so that it can be evaluated and this is why the backticks were used, but if the ouput from the Expect script ($swbt_dms) can be captured without the use of backticks this would be great. The arguement ($item) provided to the Expect script is either Datakit or IP info. So with all of this said, what would be the most appropriate method of capturing into a file (has to be into a file) the output from the Expect script so that it can be evaluated? Hay, thank you for taking time to help me with elevating my Perl knowledge.
| [reply] |
|
|
$ perl -e 'eval `echo print 1+3`';
4
Otherwise, system will do just fine:
$ perl -e 'system("echo bla > file");'
$ cat file
bla
| [reply] [d/l] [select] |
|
|
|
|
|
|
|
|
Re: exec, system, or backticks
by perlcapt (Pilgrim) on Oct 20, 2004 at 15:58 UTC
|
Strange use of your subroutine arguments. none! | [reply] |
|
|
OK, can you please explain your comment? I am not being test or anything like that, I just want to know if something can be done better or more efficent... then lets do it! Thanks, Terry.
| [reply] |
|
|
I'm studying to the code, trying to work out what is going on. My first comment was just a reaction to trying to find where the subroutine arguments were going and how used. etc.
I'm not sure about the performance differences between backticks and the system call. I do know you don't want exec because it essentially replaces the script process with the new process of the exec call. There would be no way for your next line to be reached.
Are you benchmarking the spawning of processes here? What's up? -ben (perlcapt)
UPDATE:
I came across this
Spawing other programs in Perl which might help. The big difference it useability between backticks and system() is what they return. Backticks return the stdout of the spawned process, and system() returns the exit code. -ben
| [reply] |
|
|
|
|
|
|
|
|
Re: exec, system, or backticks (or open)
by jmanning2k (Pilgrim) on Oct 22, 2004 at 14:43 UTC
|
Reading the other comments, it appears you do want the output.
Backticks will work well for this situation, but not the way you used them. Try:
$key = `$sxwbt_dms $item`
instead of the shell redirection.
This runs the entire program, and then gives you all the output.
If your program would do well reading the output line by line as the program outputs it, you will get a faster response with an open call. Just follow the program name with a pipe character, and perl will attach to the program's STDOUT.
open(SWBT, "$swbt_dms $item |")
while(<SWBT>) {
process_line($_);
}
But that depends on if you need the entire results, or you want to process it line by line.
It is just yet another way to read output from a program, but since it hasn't yet been mentioned, and has the advantage of line-by-line processing, I thought I'd mention it.
~J | [reply] [d/l] [select] |