@ARGV array incorrect when calling perl program from system

[Udo Grabowski]

Hi,

the following construction gives additional @ARGV entries which shouldn't
be there:

@command = ("perl-program","--help",">","logfile");
eval { system(@command) };

Inside perl-program (which starts with #!/usr/bin/perl),
@ARGV now contains also '>' and 'logfile' as additional
entries. This contradicts the definition of @ARGV:
"The array @ARGV contains the command-line arguments
INTENDED FOR THE SCRIPT"

Since the redirection parameters are not script parameters, they
shouldn't appear (and didn't appear before). This bug breaks all
and everything depending on @ARGV and the number of parameters !

Is this a perl bug, or is the system command of the OS responsible
for this broken behaviour ? Or even the distributor of this perl
version ?

Platform: OpenSolaris 2009.06,
Version: perl 5.8.8 (Coolstack distribution)
i86pc-solaris-thread-multi

 

[Peter Makholm]

@command = ("perl-program","--help",">","logfile");
eval { system(@command) };

Read the documentation for the system command:

If there is more than one argument in LIST, or if LIST is an array
with more than one value, starts the program given by the first
element of the list with arguments given by the rest of the list.

So of course '>' and 'logfile' is parsed to the script as script
arguments. If you need any kind of shell handling, you have to use
one, and only one, argument to system.

I can't imagine that this has changed recently on any posix like
platform.

//Makholm

 

[Udo Grabowski]

Read the documentation for the system command:

If there is more than one argument in LIST, or if LIST is an array
with more than one value, starts the program given by the first
element of the list with arguments given by the rest of the list.

So of course '>' and 'logfile' is parsed to the script as script
arguments. If you need any kind of shell handling, you have to use
one, and only one, argument to system.

So this means that calling 'perl-program --help > logfile' and
using the construction above (which should be equivalent, since
it should be transparent to the program from whom it is called)
will give inconsistent @ARGV arrays. So I still consider this
to be a bug (referring to Unix semantics) instead of a feature.

If this is really Posix' definition, then Posix is inconsistent.
But I think that 'system' called here is the perl implementation,
so maybe that is simply done wrong there.

Workaround is indeed to call it this way:
$return=system('perl-program --help > logfile')

 

[RedGrittyBrick]

So this means that calling 'perl-program --help > logfile' and
using the construction above (which should be equivalent,

No they should not be equivalent.

perldoc -f system

"Note that argument processing varies
depending on the number of arguments. If there is more than one
argument in LIST, or if LIST is an array with more than one
value, starts the program given by the first element of the list
with arguments given by the rest of the list. If there is only
one scalar argument, the argument is checked for shell
metacharacters, and if there are any, the entire argument is
passed to the system's command shell for parsing"

In one case a shell is *not* ever invoked, and therefore shell features
such as output redirection are not applicable.

In the other case, a shell *will* be invoked to process any shell
metacharacters.

since
it should be transparent to the program from whom it is called)
will give inconsistent @ARGV arrays. So I still consider this
to be a bug (referring to Unix semantics) instead of a feature.

If a program's behaviour agrees with it's documentation I consider it a
feature. No matter how much I might dislike or be confused by that feature.

Since changing this feature would break many existing Perl programs I
strongly doubt it will ever get changed in Perl 5.

 

[Udo Grabowski]

One builds the argv[] array manually, and
forks and execs your binary without ever going near a shell.

Thanks for pointing that out, it wasn't clear to me from the doc
that no shell is involved when calling it this way. Maybe
your sentence would be helpful in the doc to avoid confusion.