Re^6: $? set to strange values on failure under Win32

When an error does occur, it's found inside $! and not $^E

Could $! then be used (instead of $^E) to determine the info you need ? Looking at what you, BrowserUk, and I have posted, it seems that $! might be all you need to consider (so long as it's undeffed before the system call). Or am I missing something ?

Cheers,
Rob
Update: I have no problem with Paul's preference for Win32::Process. The variablility in $^E and $!, wrt to system(), doesn't inspire a lot of confidence.

Comment on Re^6: $? set to strange values on failure under Win32

Replies are listed 'Best First'.
Re^7: $? set to strange values on failure under Win32 by pjf (Curate) on Jul 08, 2007 at 01:34 UTC
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. Paul Fenwick Perl Training Australia	[reply]

Replies are listed 'Best First'.

Re^7: $? set to strange values on failure under Win32
by pjf (Curate) on Jul 08, 2007 at 01:34 UTC

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.

Paul Fenwick
Perl Training Australia

[reply]