Using $! may be a possibility, but I've decided that moving with your suggestion of Win32::Process is better. It appears to be more consistent across operating systems, it allows us to access the whole 16 bits of the command's return value, it can be used to check if the command was successfully executed, and (at least on my system) it sets $^E to a meaningful value on failure.
I've also discovered that my problem isn't unique to Windows. Under Unix, if Perl uses the shell then a value of 127 >> 8 is placed into $? on failure to find the command, which is indistinguishable from the command completing with a return of 127. Fundamentally, whenever we invoke the shell, we lose the ability to tell the difference between our final command failing to spawn, or spawning but returning a funny value. One should stress the wisdom of avoiding commands that return 1 under Windows, or 127 under Unix.
It appears that Windows will still try to invoke the shell even if called with a multi-argument system(), whereas under Unix this never happens.
The whole thing is still a huge pain for what I'm trying to achieve, but at least it's a (mostly) consistent huge pain across platforms.
In reply to Re^7: $? set to strange values on failure under Win32
by pjf
in thread $? set to strange values on failure under Win32
by pjf
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |