in reply to Re^2: win32 parenthesis system weirdness
in thread win32 parenthesis system weirdness

Dunno. It works for me with 5.8.9 & 5.10.1. If I omit the 'dir ' from my example, it loads the image into the default image viewer. No leading space required.

Admittedly I haven't bothered to exactly replicate your weird path. Perhaps that is somehow fooling Perl's command parser into believing that the first part of the path is actually a command and is therefore bypassing the shell and failing.

If it is a bug, it's probably too obscure to be bothered trying to fix. You have a workaround, though avoiding weird dir names might be easier :)


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"I'd rather go naked than blow up my ass"
  • Comment on Re^3: win32 parenthesis system weirdness

Replies are listed 'Best First'.
Re^4: win32 parenthesis system weirdness
by ldln (Pilgrim) on Dec 04, 2009 at 10:08 UTC
    Don't think using parenthesis in dirnames is that unusual ;)?! It's not just that single parenthesis at the end that causes this behavior. Paths like this also won't open without that extra space:
    my $fn = q{ C:\img\del me\pic (images)[2k]\00000253.jpg"};
    Tried with perl 5.10 also, but same behaviour:
    #works (note extra space required) "H:\TEST\ActivePerl-5.10.0.1001-MSWin32-x86-283495\perl\bin\perl.exe" +-e "my $fn = ' \"C:\img\del me\three (3\00000253.jpg\"'; system($fn)" #Doesn't work "H:\TEST\ActivePerl-5.10.0.1001-MSWin32-x86-283495\perl\bin\perl.exe" +-e "my $fn = '\"C:\img\del me\three (3\00000253.jpg\"'; system($fn)" 'C:\img\del' is not recognized as an internal or external command, operable program or batch file.
    But since this doesn't work either (as mentioned by ikegami):
    cmd.exe /c "C:\img\del me\three (3\00000253.jpg"
    Then I don't consider this whole problem to be perl related.

    What I now need to understand is why the "(" char is treated in this special way in windows and what other chars create similar weird behaviour? Didn't think "(" was spcecial "meta-char", like | or > etc, that needed to be escaped (and even escaping it with ^ also didn't work).

      '(' and ')' are special characters. They are used grouping commands like:

      >(md x && cd x) || (echo "Couldn't create x" & exit)

      The rules for how cmd.exe treats quotes (usefully provided by help cmd), are as follows:

      If /C or /K is specified, then the remainder of the command line after the switch is processed as a command line, where the following logic i +s used to process quote (") characters: 1. If all of the following conditions are met, then quote charact +ers on the command line are preserved: - no /S switch - exactly two quote characters - no special characters between the two quote characters, where special is one of: &<>()@^| - there are one or more whitespace characters between the two quote characters - the string between the two quote characters is the name of an executable file. 2. Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the last quote character on the command line, preservin +g any text after the last quote character. ... The special characters that require quotes are: <space> &()[]{}^=;!'+,`~

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        That solved/explained it nicely.

        Thanks BrowserUk.