invoking system commands from a perl script

[vabby]

Hi
I want to know what is the diff b/w the following two ways of invoking
system commands from a perl script:
1) system(" rm abc.txt");
2)`rm abc.txt';

also of I mix and match the two styles, will i land into trouble, eg
if i have to create a file and in the next step delete it, which one
of the two ways will land me into trouble:
1)
system ("touch abc.txt");
'rm abc.txt';

or
2)

`touch abc.txt`;
system("abc.txt");

 

[anno4000]

Hi
I want to know what is the diff b/w the following two ways of invoking
system commands from a perl script:
1) system(" rm abc.txt");
2)`rm abc.txt';

Read "perldoc system" and the section about "qx" in "perldoc perlop".
The relationship is discussed in these documents.

also of I mix and match the two styles, will i land into trouble, eg
if i have to create a file and in the next step delete it, which one
of the two ways will land me into trouble:
1)
system ("touch abc.txt");
'rm abc.txt';

or
2)

`touch abc.txt`;
system("abc.txt");

None of these will necessarily land you in trouble, except with Perl
stylists. Using `` in void context is always bad style.

Anno

 

[John W. Krahn]

I want to know what is the diff b/w the following two ways of invoking
system commands from a perl script:
1) system(" rm abc.txt");

perldoc -f system

2)`rm abc.txt';

perldoc -f qx

also of I mix and match the two styles, will i land into trouble, eg
if i have to create a file and in the next step delete it, which one
of the two ways will land me into trouble:
1)
system ("touch abc.txt");
'rm abc.txt';

or
2)

`touch abc.txt`;
system("abc.txt");

How about using perl to do it (this is after all a Perl group.)

open my $fh, '>', 'abc.txt' or die "Cannot open 'abc.txt' $!";
close $fh or die "Cannot close 'abc.txt' $!";

unlink 'abc.txt' or die "Cannot unlink 'abc.txt' $!";




John

 

[Jürgen Exner]

I want to know what is the diff b/w the following two ways of invoking
system commands from a perl script:
1) system(" rm abc.txt");
2)`rm abc.txt';

See the readily available documentation for each command:
perldoc -f system
perldoc -f perlop (and see the section about quotes and quote-like
operators)

also of I mix and match the two styles,

Those are not different styles. Those are two different commands that simply
do different things.

will i land into trouble, eg
if i have to create a file and in the next step delete it, which one
of the two ways will land me into trouble:

It's like asking if you can mix multiplication and addition in the same Perl
program.
They just do different things. Choose the one that is the right for your
task.

system ("touch abc.txt");

You should check if your call to system was successful.

'rm abc.txt';

I suppose you mean
`rm abc.txt`;
What output do you expect from the rm(1) command? Why are you asking for the
output if you don't capture it?

jue

 

[Dr.Ruud]

(e-mail address removed)-berlin.de schreef:

Read "perldoc system"

ITYM: perldoc -f system
or: perldoc -q system

 

[vabby]

so using backticks or system is teh same thing except when you want to
capture the result value of teh command. my idea of asking the
question was that somebody told me , that using system to execute unix
commands, is the synchronous way of doing it, and using backticks the
asynchronous way

 

[anno4000]

so using backticks or system is teh same thing except when you want to
capture the result value of teh command.

Its *output*. The term "result value" is ambiguous at best.

my idea of asking the
question was that somebody told me , that using system to execute unix
commands, is the synchronous way of doing it, and using backticks the
asynchronous way

If by "synchronous" you mean you don't get control back before the
command has been executed, both are synchronous. To get asynchronous
behavior, in the sense that your Perl program keeps running while the
external program executes, you'll need forking. That can happen
directly or through appropriate calls of open().

Anno

 

[Uri Guttman]

a> Its *output*. The term "result value" is ambiguous at best.

a> If by "synchronous" you mean you don't get control back before the
a> command has been executed, both are synchronous. To get asynchronous
a> behavior, in the sense that your Perl program keeps running while the
a> external program executes, you'll need forking. That can happen
a> directly or through appropriate calls of open().

well, you know both system and backticks fork too. the synchronous part
is that they wait until they complete. open | is one way to run an async
process and IPC:pen2/3 are some others. and as you implied calling
fork (and maybe exec) directly is another.

uri

 

[Jamie]

so using backticks or system is teh same thing except when you want to
capture the result value of teh command. my idea of asking the
question was that somebody told me , that using system to execute unix
commands, is the synchronous way of doing it, and using backticks the
asynchronous way

Backtics are a sort of hackish way to get the output of the command (output
as in, standard output, NOT the result)

They're like the shell counterparts. In a standard shell, you can:

-------------- shell ----------
TOP=`pwd`
echo $TOP
------------------------------


In perl, you can also do this:

open(PIPE,"pwd |");
while(<PIPE>){
...
}
close(PIPE);

Have to be a little careful with backtics. (actually, I sort of wish perl
didn't have them as they are confusing with ')

To get the "result", (error code) you want to look at the $? variable, sorta
like this:

my $rc = ($? >> 8);


They all involve forking (at least on a unix platform) the difference is,
things like backtics or system will wait() for the process to terminate
before returning control back to you. This is generally what you want, if
your task can't resume until something is done by the system.

fork() and open(PIPE,"command_name |"); will launch the process and then
return to you before the command completes. (in the above case, close()
waits for the command to complete) This allows you to process the data
from the shell command "as it happens" as opposed to "all at once".


Jamie

 

[Uri Guttman]

J> Backtics are a sort of hackish way to get the output of the command (output
J> as in, standard output, NOT the result)

hackish??? they are a perfectly normal and proper way to get all the
stdout of a subprocess.

J> They're like the shell counterparts. In a standard shell, you can:

they were totally borrowed/stolen from the shell. like many other perl
features were.

J> Have to be a little careful with backtics. (actually, I sort of
J> wish perl didn't have them as they are confusing with ')

so use qx() instead. hard to confuse those with single quotes.


J> To get the "result", (error code) you want to look at the $?
J> variable, sorta like this:

J> my $rc = ($? >> 8);

why sorta?? i wouldn't call that the "result" either as few programs use
the exit code (not error code) for real communication. a typical
subprocess called under qx will just send output to stdout.

J> They all involve forking (at least on a unix platform) the difference is,
J> things like backtics or system will wait() for the process to terminate
J> before returning control back to you. This is generally what you want, if
J> your task can't resume until something is done by the system.

J> fork() and open(PIPE,"command_name |"); will launch the process and then
J> return to you before the command completes. (in the above case, close()
J> waits for the command to complete) This allows you to process the data
J> from the shell command "as it happens" as opposed to "all at once".

and in most common subprocess cases there won't be much difference. the
choice is more about how much output is generated (due to buffering
needs) and how long the subprocess takes to run. some bigger differences
is whether the shell is invoked in the middle and that open |'s exit
code is returned by close. and you still need the same >>8 stuff to get
the "exit" code.

uri

 

[Joe Smith]

somebody told me , that using system to execute unix
commands, is the synchronous way of doing it, and using backticks the
asynchronous way

Both are synchronous unless the shell metacharacter "&" is used for background
execution. Using "&" with backticks is not very useful.
-Joe