Re^6: Poll: Is your $^X an absolute path? (system @list)

[xdg]

I think the safe thing is to always surround the first argument with double-quotes if more than one argument is provided and it doesn't already seem to have double quotes. (If only one argument is provided, we have to assume the user provided a valid command line on the current platform.) So, ignoring error reporting, something like this:

sub system {
  $_[0] = qq{"$_[0]"} if @_ > 1 && substr($_[0],0,1) ne q{"};
  CORE::system( @_ );
}

On reflection, that seems simple enough that maybe we can get some p5p person to patch it.

Some references about how spaces are handled in program names:

• CreateProcess
• CreateProcess tries to DWIM

[tye]

assume the user provided a valid command line on the current platform

Which translates to "avoid portability". I strongly disagree.

Look at existing attempts to provide portability with command lines in Perl. Several Perl subsystems compose lists of which command to use to do which task and then expect system($command{copy},$from,$to) to work. That is quite reasonable. Too bad it doesn't work very well on Win32. But that is because system(@list) has always been broke on Win32, depriving an important tool for dealing with command lines portably in Perl.

Unfortunately, we can't make system(@list) work portably for all Win32 commands but we can make it work portable for most commands, and we should do that.

But you do remind me of a point that I had previous included in my proposal but that I didn't include in the one I linked to. We should probably not add quotes if there are already quotes around the argument. I can see advantages to either way so perhaps it should be an option, but the default should be to avoid adding quotes if they are already there.

[xdg]

I go back to perlport:

 Interprocess Communication (IPC)
   In general, don't directly access the system in code meant to be
   portable. That means, no "system", "exec", "fork", "pipe", ``, "qx/
+/",
   "open" with a "|", nor any of the other things that makes being a p
+erl
   hacker worth being.

Relying on external programs is fundamentally non-portable, even if it works much of the time. Vanilla Perl has made me very aware of just how fragile lots of the assumptions about "make", "nmake" and "dmake" are.

I agree totally that we should try to be helpful in the case of system(@list) and ensure the first argument is quoted if its not. But the semantics for system($line) are messy.

Should we do the same workaround as CreateProcess and walk the command line, joining up spaces into the first argument until we find something that can execute and then wrap that in quotes?

sub auto_quote_system {
    my $line = shift;
    my @parts = split " ", $line;
    my $cmd = shift @parts;
    while ( ! -x $cmd ) {     # does -x works for file associations?
        $cmd .= " " . shift @parts;
    }
    return qq{"$cmd" @parts};
}

Even that's not complete. It doesn't deal well with multiple spaces in an executable path nor with commands that can't be found. And note the unexpected result or trojan potential of a program called C:\program.exe. I think that could quickly wind up with a very convoluted kludge.

I'm more comfortable saying that if you call system($line) then it's up to you to make sure that the line is valid for your OS, particularly if we can patch system and perlport docs to advise that wrapping the first argument in a quotes is a good idea.

[BrowserUk]

I'm more comfortable saying that if you call system($line) then it's up to you to make sure that the line is valid for your OS,

Seconded.

Almost every place where the sources attempt to "compensate" for Win32's non-*nix nature and behaviour, I find myself forced to find intricate work arounds to bypass those attempts, in order to use the facilities the OS provides.

Personally, I think portability issues should be dealt with:

1. when required; not 'in case'.
2. At the user level; not the perl level.
3. At the block level; not the statement level.

[tye]

Nice straw man. I didn't advocate changing system($line) so arguing how that is a bad idea doesn't really support your point that system(@list) shouldn't be fixed on Win32 to (almost) work as documented (and how it works on other Perls).

But we should fix system(@list) to work as system(@list) is defined by the Perl documentation, as much as practical. Passing arguments to some command is something that is often needed. There really isn't anything not portable about code like:

system( $yourConfiguredEditor, $fileName )

Nor is there some more portable way to enable a script to launch your favorite editor on some file.

And there is no reason to desire that everyone who does anything like that to have to write code like this instead:

    if(  $^O =~ /Win32/  ) {
        system( qq("$yourEditor" "$fileName") );
    } els...

This is just a long-standing bug that should be fixed. Your position that we should improve the situation by requiring people to instead write:

    if(  $^O =~ /Win32/  ) {
        system( $yourEditor, qq("$fileName") );
    } els...

makes little sense to me. (: