I read that multiple times :-) (I wouldn't dare post otherwise). I guess my problem is that I don't understand what it says.

What are "shell metacharacters"? All those variables are defined in the Perl script, so they should be resolved in the script. Are \" shell metacharacters? And what about > and <? They occur in Perl when you open a pipe, but this is sort of different...or maybe not...?

Also, what difference does it make whether Perl starts qrsh with that whole list of arguments, or whether the shell does? And when Perl starts qrsh, what about > and <, *if* they are "shell metacharacters"? How do they get interpreted?

In the one-argument case, I can print the whole string to see what it is resolved to. But what about the multiple argument case? How do I know what that really works out to (so that I can write the same thing in when I call capture_exec)?

What are "shell metacharacters"?

[ddg://What are "shell metacharacters"?] What are "shell metacharacters"? ... Characters used for input or output in UNIX shells having special meaning.

Yes, the two forms are different.

In the first form, a system call (eg, the C function as implemented internally by the operating system for executing commands) is made with the arguments provided. In the second form, the string is passed to the shell to deal with. The difficulty that you are running into is with escaping of meta-characters (characters special to the shell, but not special to the internal system call).

The first form (system call) is equivalent to automatically escaping all arguments. So when you say above that the first form "works", it really doesn't, as it just passes ">$output_file" as an argument to the command, which in general won't do what you want. I don't know of any way to do something like piping to a file using the first form (you normally use open() for that instead).

The second form (shell command) probably doesn't work for you because you are not escaping characters that you want escaped. Escaping can be done automatically in Perl using quotemeta() or \Q...\E.

As an example, consider:

If you want this to echo "two > one", then you need to escape the ">":

If you want "two" to be piped to a file called "one", then you don't:

Thanks Arnon. That answer was useful. I suspect the 1st form works because of the specifics here (qrsh is a Sun Grid Engine command which opens a shell on a node and runs "lens ... 2>$logfile"). I didn't realize it made a difference for the answer.

I finally found out what characters exactly needed to be escaped how many times

system "qrsh $qrsh_options \"lens -n \\\"source $qscript ; test_model 
+$arguments\\\" >$output_file 2>$logfile\"";
[download]

I just read about quotemeta and I suspect it wouldn't work for me because all the $ would be escaped and the perl variables wouldn't be resolved. But I will remember \Q...\E for the future - I'm sure it will come in handy sometime :-)

I think the other posters roughly said it already, but I'll elaborate a bit from a systems programming standpoint.

system($str) is equivalent, OS-wise, to forking, and then exec'ing sh -c "$str"

system(@list) is equivalent to forking, setting ARGV to @list, and exec'ing the first item in @list.

In the latter form, there is no shell involved, which means one fewer fork (more efficient), no need to think about escaping things for the shell (wonderful), and that it is a bit safer against untrusted input. On the downside, you cannot use shell features such as redirection or pipes.

You are free to test what happens if you call this small perl script, let's call it showargs.pl with both styles:

#!/usr/bin/perl
use Data::Dumper;
print Dumper(\@ARGV);
[download]

Calling it with the following snippet, what do you expect the output to be? What about without the list-form invocation?

system 'showargs.pl', 'lens', '-n', "\"source $qscript; 
test_model $arguments\"", ">$output_file", "2>$logfile";
[download]