Did you close and restart whatever "session" you were running your scripts from following the Perl install and include path change? The session's version of the include path wouldn't be affected by any changes made outside the session or any changes made in child sessions.

Yes - definitely. After some experimentation - and with careful changes to path environment - checking that path has been reloaded prior to running perl - I have found: v5.12.0 will work. v5.12.3 won't work. In both cases I am reasonably confident that there is only one perl.exe on the path at any one time. In both cases 'system' does work correctly with the same parameters as given to 'exec'. I am not saying there is a bug - just commenting on my experience in my installation. Thanks, Ross.

although perl is on the path environment variable

Did you also check whether ther are maybe TWO files with a name like perl.* in your PATH?

This script:

#    Test perl execution
system "perl", "d:\\src_test\\perl\\hi.pl";
system "echo %path%";
system "which perl";
exec "perl", "d:\\src_test\\perl\\hi.pl";
[download]

Shows the path. The which program shows only the expected Perl.exe file. Here is the script output:

Hello world
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\Sys
+tem32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\ATI Technologies
+\ATI.ACE\Core-Static;C:\Program Files\WIDCOMM\Bluetooth Software\;C:\
+Program Files\WIDCOMM\Bluetooth Software\syswow64;D:\app\sql\product\
+11.2.0\client_1\bin;C:\Program Files (x86)\Java\jdk1.6.0_20\bin;d:\op
+t\ant\bin;C:\Program Files\Scite;C:\Program Files (x86)\GnuWin32\bin;
+C:\Program Files (x86)\WinMerge;D:\opt\apache-maven-2.2.1\bin;d:\orac
+le;D:\opt\OracleXeClient\bin;D:\opt\OracleXe\app\oracle\product\10.2.
+0\server\bin;D:\opt\SpringSource\spring-roo-1.2.0.RELEASE\bin;C:\Prog
+ram Files\SlikSvn\bin\;C:\Program Files (x86)\Microsoft SQL Server\10
+0\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C
+:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (
+x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\;C:\Prog
+ram Files (x86)\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (
+x86)\QuickTime\QTSystem\;C:\Program Files\7-Zip;C:\Program Files (x86
+)\Programmer's Notepad\;D:\Ruby187\bin;C:\Program Files (x86)\Microso
+ft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\; C:\Program Files
+ (x86)\ActiveState Komodo Edit 6\;D:\opt\scala-2.9.0.1\bin;c:\Program
+ Files\Sublime Text 2;C:\Program Files\TortoiseSVN\bin;C:\Program Fil
+es (x86)\Windows Live\Shared;C:\Program Files\Common Files\Microsoft 
+Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Sha
+red\Windows Live;d:\opt\strawberry\perl\bin;d:\opt\strawberry\perl\si
+te\bin;d:\opt\strawberry\c\bin;d:\opt\util;D:\opt\SpringSource\spring
+-roo-1.2.0.RELEASE\bin
d:\opt\strawberry\perl\bin\perl.EXE
Can't exec "perl": Invalid argument at D:\src_test\perl\test_exec.pl l
+ine 5.
[download]

Note that the first system and the last exec statement are provided with identical arguments - the exec throws an exception but the same earlier call to system doesn't. I do have a separate, older Perl installation - not on the path - which was not completely removed. When I installed the new Perl, I didn't un-install that Perl except I did remove it from the path. If I now change the path back to point at the older Perl build, I get the same broken behaviour of exec.

So the problem is my installation. If I want to fix it I may have to fully un-install both Perls.

Thank you for your help rovf.