Incorrect quoting of command-line arguments for all programs in Perl\exec

Perl
5

Hi Nathan,

If you find the paths misleading, perhaps you didn’t realize that I chose my own --runtime-path? Let me go into details…

  1. I did request and install exiftool from ActiveState (the 4th package in the list):
C:\Users\root>state packages
█ Listing Packages

Operating on project gamin-mb/Perl-5.36-Windows, located at C:\Users\root\Perl-5.36-Windows.

  Name                   Version
──────────────────────────────────
  Excel-Writer-XLSX      Auto
  File-chdir             Auto
  File-Copy-Recursive    Auto
  Image-ExifTool         Auto
  PAR-Packer             Auto
  PadWalker              Auto
  Pod-Simple-Wiki        Auto
  Spreadsheet-Read       Auto
  Term-ProgressBar       Auto
  Test-Cmd               Auto
  Text-CSV_XS            Auto
  Win32-API              Auto
  Win32-Console          Auto
  Win32-File             Auto
  XML-LibXML             Auto

In addition, there are references to “exiftool.exe” and “c:\perl\site\bin\exiftool” in C:\Perl\exec\meta.as and in files under C:\Users\root\AppData\Local\ActiveState\cache\artifacts, which are files or folders created by ActiveState.

  1. I installed Perl as instructed by your support team, as discussed here: How do I get rid of extra runtimes?. More specifically, I did the following, in this order, on January 23, 2024:
I deleted C:\Perl
state clean uninstall --all
I deleted C:\Users\root\Perl-5.36.0-Windows
I downloaded state-remote-installer.exe from ActiveState
state-remote-installer.exe
state checkout gamin-mb/Perl-5.36-Windows --runtime-path C:/Perl
state use Perl-5.36-Windows

I also performed a few state pull; on January 25, February 16, and February 26 or 27.

  1. As I pointed out at the beginning of my first message, the error occurs not only with exiftool but with every program installed by the state tool in C:\Perl\exec or in …\AppData\Local\activestate\cache\bin. None of these programs seem to be allowed to run when passed a command-line argument containing an input redirection character (<), even if the character is quoted. See for instance what happens with as basic a command as this:

C:\Users\root>C:\Users\root\AppData\Local\activestate\cache\bin\pod2text.exe "a<b"
The system cannot find the file specified.

To simplify:

Let’s eliminate all these variables, and use a simple script that we can share: put the following line in a file called testarg.txt:
printf "Argument: '%s'.\n", $ARGV[0];
This script should print the first command-line argument and exit. Note that I chose to give the script a .txt extension, and I call perl explicitly on it to prevent Windows from choosing some command from the registry that might quote (or not) its arguments.

This is the output I get. The first one is expected, the second one is an error, the third one is an error and it also created a file named “b”, whose contents is “Argument: ‘a’.”:

C:\Users\root>C:\Users\root\AppData\Local\activestate\cache\bin\perl.exe testarg.txt “a<b”
Argument: ‘a<b’.

C:\Users\root>state exec perl testarg.txt “a<b”
Operating on project gamin-mb/Perl-5.36-Windows, located at C:\Users\root\Perl-5.36-Windows.

The system cannot find the file specified.

C:\Users\root>state exec perl testarg.txt “a>b”
Operating on project gamin-mb/Perl-5.36-Windows, located at C:\Users\root\Perl-5.36-Windows.

The second and third cases are consistent with Windows interpreting the argument as if the quotes weren’t present, which gives me a strong suspicion that state-exec drops the quotes around its arguments. I guess most of the executables under Perl\exec are in fact renamed copies of state-exec, and therefore they inherit the problem.

When you run my testarg.txt under the same conditions, what do you get? If it works for you, then I’ll scratch my head to find another explanation.

Thanks,

Martin