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.
[download]

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};
}
[download]

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.

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.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

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.

Note that your response is to a straw man which doesn't apply to my proposal to fix system(@list) on Win32. And if somehow my proposed fix caused behavior that was not desired by you in some situation, then the "intricate work-around" to get the old behavior is system("@list"). Terribly difficult. :)

- 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 )
[download]

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...
[download]

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...
[download]

makes little sense to me. (:

- tye        

Wow. Today really seems to be my day for talking past people. Maybe I should stop posting any more today -- there must be something in the air.

Nice straw man. I didn't advocate changing system($line)

Going way back in the thread, I'd suggested 'if only one argument is provided, we have to assume the user provided a valid command line on the current platform', from which you quoted the 'assume...' part and said '...I strongly disagree'. That's what prompted my response.

To use a co-worker's term, I think you, me and BrowserUK are in violent agreement that system(@list) on win32 should be fixed to quote the initial argument, but that system($line) is up to the user to do the right thing.

As a minor note, my suggestion about documenting a recommendation of double quotes was only for the system($line) form, like so:

if ( $^O =~ /Win32/ ) {
    system( qq{"$yourEditor" "$filename"} );
}
[download]

There should be a general warning in docs for the system($line) form about making assumptions about spaces in filenames. On linux, they can be escaped with backslashes. On Win32, each argument that might have spaces needs to be wrapped in quotes. And so on.

Generally, I think people should be encouraged to use system(@list) unless they really need to depend on the shell for something (e.g. file redirection).

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.