spikkie has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks, this question is regarding the special variable $? Is there a known portability issue between Perl and Windows related to + $? When I use the following piece of code #--------------------------------------------- my $cmd = "$search_application something"; my $ret = qx($search_application); unless ( $? == 0 ) { print "value \$? : $?\n"; die "Something not found\n"; } #--------------------------------------------- on Unix the $? has value 256 which is correct. But on windows $? stays 0 which I can not explain. When I run the command in a shell both unix and windows shell variable +s $? and %ERRORLEVEL% are "1" so the application is not the problem. Thanx in advance!

Replies are listed 'Best First'.
Re: usage of $? in windows
by rovf (Priest) on Mar 04, 2010 at 12:15 UTC
    If $? equals 0, we can at least deduce that, even on Windows, your spawned process (which might be either CMD.EXE, or the program you want to invoke - this depends on how the variables you use inside qx(...) expand - did NOT return exit code 1.

    Apart from this, one difference between Windows and Unix is that Unix return codes are 8 bit, while on Windows they are 32 bit, with the effect that 24 bits get lost.

    -- 
    Ronald Fischer <ynnor@mm.st>

      Hi Ronald

      thanx!

      But for me this does not explain why the spawned process returns an error in unix and not in windows. The spawned process runs another encrypted perl script. Is there any way I can debug this?

      Thanx in advance

      spikkie

        $? == 256 means the child called exit(1) (256>>8 = 1). Chances are that the value (1) is not significant beyond meaning an error occurred. You'd think it would have emitted a message to STDERR identifying the error.

        $ perl -le'qx{date abc}; print $?' date: invalid date `abc' 256

        One likely cause is improper escaping of arguments. Print out $cmd, check for bad quoting, and try that same command at the prompt.

        $ perl -le'qx{cat some file}; print $?' cat: some: No such file or directory cat: file: No such file or directory 256 $ perl -le'qx{cat "some file"}; print $?' 0

        You mentioned the child is some kind of searching utility. An error could also indicate no matches were found.

        $ perl -le'qx{echo foo | grep bar}; print $?' 256 $ perl -le'qx{echo foo | grep foo}; print $?' 0

        The program's man page might identify situations where it might return an error.

        You mean: Why you get different exit codes? (In both cases, the *error* is 0, but on Unix you see exit code 1 and on Windows you see exit code 0). Could it be that on Windows, a shell is running between your perl program and the application, and this is "eating" the exit code of the application? Do you get the same effect if you bypass the shell?

        Another thing to try is to replace your application by one where you can control the exit code directly. For instance when I execute (on Windows 2000) the program

        use strict; use warnings; my $r=qx(set|perl -lwe "print <STDIN>; exit 1"); print "$?\n";
        I get correct the exit code 1 (i.e. 256). What do you get in this case?

        -- 
        Ronald Fischer <ynnor@mm.st>