Keep It Simple, Stupid | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
You can distinguish between a successfully run command returning 1 and a failed command by checking $^E. If $^E is empty, the command ran successfully and the contents of $? are the lower 8 bits << 8 of the 16-bit value returned by the executable. If $^E is set, usually to The system cannot find the file specified, then the command could not be found--either directly, nor by running cmd.exe passing the parameter(s) supplied on the system call as argument(s) in the hope it can be resolved via the path--and $? contains the failure code (1) from cmd.exe. This is when the ...' is not recognised as an internal or external command message is produced. This can be suppressed by redirecting stderr to null as in the 3rd example below:
The real problem here is that the win32 implementation of the posix system call attempts to emulate that call as best it can. So, for example, return codes from executables above 255 get truncated to 8-bits and shifted left to leave room for signal values, which you can never receive. And even if you supply multiple arguments to system, if the first attempt to run the command directly fails, it defaults to trying again, by supplying the commands you supply, to 'cmd.exe' to see if it can find the command. This is not an exhaustive explanation of what goes on in Win32.c. I seem to recall tye posting a pretty comprehensive breakdown, but I can't persuade google to find it for me. You might also want to look into using SetErrorMode() to (optionally) suppress system popups for things like segfaults and 'Insert disk for drive x:' and similar.. 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.
In reply to Re: $? set to strange values on failure under Win32
by BrowserUk
|
|