Perldoc Search: "$?" perl-5.20.1

search official POD


9 PODs, 60 LINEs found.
perlfunc.pod
447 :         If the filehandle came from a piped open, "close" returns false if one of the other syscalls involved fails or if its program exits with non-zero status. If the only problem was that the program exited non-zero, $! will be set to 0. Closing a pipe also waits for the process executing on the pipe to exit--in case you wish to look at the output of the pipe afterwards--and implicitly puts the exit status value of that command into $? and "${^CHILD_ERROR_NATIVE}".
460 :                            : "Exit status $? from sort";
680 :         If an uncaught exception results in interpreter exit, the exit code is determined from the values of $! and $? with this pseudocode:
683 :             exit $? >> 8 if $? >> 8;    # child exit status
951 :         The first version, the one without the indirect object, ran the *echo* program, passing it "surprise" an argument. The second version didn't; it tried to run a program named *"echo surprise"*, didn't find it, and set $? to a non-zero value indicating failure.
1015 :         The exit() function does not always exit immediately. It calls any defined "END" routines first, but these "END" routines may not themselves abort the exit. Likewise any object destructors that need to be called are called before the real exit. "END" routines and destructors can change the exit status by modifying $?. If this is a problem, you can call "POSIX::_exit($status)" to avoid END and destructor processing. See perlmod for details.
1299 :         For the *gethost*()* functions, if the "h_errno" variable is supported in C, it will be returned to you via $? if the function call fails. The @addrs value returned by a successful call is a list of raw addresses returned by the corresponding library call. In the Internet domain, each address is four bytes long; you can unpack it by saying something like:
2088 :         Closing any piped filehandle causes the parent process to wait for the child to finish, then returns the status value in $? and "${^CHILD_ERROR_NATIVE}".
4221 :                 or die "system @args failed: $?"
4223 :         If you'd like to manually inspect "system"'s failure, you can check all possible failure modes by inspecting $? like this:
4225 :             if ($? == -1) {
4228 :             elsif ($? & 127) {
4230 :                     ($? & 127),  ($? & 128) ? 'with' : 'without';
4233 :                 printf "child exited with value %d\n", $? >> 8;
4823 :         Behaves like wait(2) on your system: it waits for a child process to terminate and returns the pid of the deceased process, or -1 if there are no child processes. The status is returned in $? and "${^CHILD_ERROR_NATIVE}". Note that a return value of -1 could mean that child processes are being automatically reaped, as described in perlipc.
4830 :         Waits for a particular child process to terminate and returns the pid of the deceased process, or -1 if there is no such child process. On some systems, a value of 0 indicates that there are processes still running. The status is returned in $? and "${^CHILD_ERROR_NATIVE}". If you say
perlipc.pod
62 :                 $Kid_Status{$child} = $?;
76 :             # don't change $! and $? outside handler
77 :             local ($!, $?);
80 :                 cleanup_child($pid, $?);
247 :         close SPOOLER       || die "bad spool: $! $?";
257 :         close STATUS        || die "bad netstat: $! $?";
268 :         die "bad netstatus ($?)" if $?;
284 :         close(FH)           || die "can't close: status=$?";
334 :             close(KID_TO_WRITE)     || warn "kid exited $?";
358 :             close(KID_TO_READ)  || warn "kid exited $?";
376 :             close(KID_TO_WRITE) || warn "kid exited $?";
680 :             while ((my $pid = waitpid(-1, WNOHANG)) > 0 && WIFEXITED($?)) {
681 :                 logmsg "reaped $waitedpid" . ($? ? " with exit $?" : "");
829 :                 logmsg "reaped $waitedpid" . ($? ? " with exit $?" : "");
perlvar.pod
820 :     The variables $@, $!, $^E, and $? contain information about different types of error conditions that may appear during execution of a Perl program. The variables are shown ordered by the "distance" between the subsystem which reported the error and the Perl process. They correspond to errors detected by the Perl interpreter, C library, operating system, or an external program, respectively.
827 :             close $pipe or die "bad pipe: $?, $!";
832 :     $@ is set if the string to be "eval"-ed did not compile (this may happen if "open" or "close" were imported with bad prototypes), or if Perl code executed during evaluation "die()"d. In these cases the value of $@ is the compile error, or the argument to "die" (which will interpolate $! and $?). (See also Fatal, though.)
836 :     Finally, $? may be set to non-0 value if the external program /cdrom/install fails. The upper eight bits reflect specific error conditions encountered by the program (the program's "exit()" value). The lower eight bits reflect mode of failure, like signal death and core dump information. See wait(2) for details. In contrast to $! and $^E, which are set only if error condition is detected, the variable $? is set on each "wait" or pipe "close", overwriting the old value. This is more like $@, which on every "eval()" is always set on failure and cleared on success.
838 :     For more details, see the individual descriptions at $@, $!, $^E, and $?.
843 :             Under VMS this reflects the actual VMS exit status; i.e. it is the same as $? when the pragma "use vmsish 'status'" is in effect.
920 :     $?      The status returned by the last pipe close, backtick (``) command, successful call to "wait()" or "waitpid()", or from the "system()" operator. This is just the 16-bit status word returned by the traditional Unix "wait()" system call (or else is made up to look like it). Thus, the exit value of the subprocess is really ("$? >> 8"), and "$? & 127" gives which signal, if any, the process died from, and "$? & 128" reports whether there was a core dump.
922 :             Additionally, if the "h_errno" variable is supported in C, its value is returned via $? if any "gethost*()" function fails.
924 :             If you have installed a signal handler for "SIGCHLD", the value of $? will usually be wrong outside that handler.
926 :             Inside an "END" subroutine $? contains the value that is going to be given to "exit()". You can modify $? in an "END" subroutine to change the exit status of your program. For example:
929 :                     $? = 1 if $? == 255;  # die would make it 255
932 :             Under VMS, the pragma "use vmsish 'status'" makes $? reflect the actual VMS exit status, instead of the default emulation of POSIX status; see "$?" in perlvms for details.
perlvms.pod
269 :     die "die" will force the native VMS exit status to be an SS$_ABORT code if neither of the $! or $? status values are ones that would cause the native status to be interpreted as being what VMS classifies as SEVERE_ERROR severity for DCL error handling.
271 :         When "PERL_VMS_POSIX_EXIT" is active (see "$?" below), the native VMS exit status value will have either one of the $! or $? or $^E or the Unix value 255 encoded into it in a way that the effective original value can be decoded by other programs written in C, including Perl and the GNV package. As per the normal non-VMS behavior of "die" if either $! or $? are non-zero, one of those values will be encoded into a native VMS status value. If both of the Unix status values are 0, and the $^E value is set one of ERROR or SEVERE_ERROR severity, then the $^E value will be used as the exit code as is. If none of the above apply, the Unix value of 255 will be encoded into a native VMS exit status value.
277 :         See "$?" for a description of the encoding of the Unix value to produce a native VMS status containing it.
315 :         Perl waits for the subprocess to complete before continuing execution in the current process. As described in perlfunc, the return value of "system" is a fake "status" which follows POSIX semantics unless the pragma "use vmsish 'status'" is in effect; see the description of $? in this document for more detail.
349 :         If PID is a subprocess started by a piped "open()" (see open), "waitpid" will wait for that subprocess, and return its final status value in $?. If PID is a subprocess created in some other way (e.g. SPAWNed before Perl was invoked), "waitpid" will simply check once per second whether the process has completed, and return when it has. (If PID specifies a process that isn't a subprocess of the current process, and you invoked Perl with the "-w" switch, a warning will be issued.)
411 :     $?  The "status value" returned in $? is synthesized from the actual exit status of the subprocess in a way that approximates POSIX wait(5) semantics, in order to allow Perl programs to portably test for successful completion of subprocesses. The low order 8 bits of $? are always 0 under VMS, since the termination status of a process may or may not have been generated by an exception.
427 :         As a result, $? will always be zero if the subprocess's exit status indicated successful completion, and non-zero if a warning or error occurred or a program compliant with encoding _POSIX_EXIT values was run and set a status.
429 :         How can you tell the difference between a non-zero status that is the result of a VMS native error status or an encoded Unix status? You can not unless you look at the ${^CHILD_ERROR_NATIVE} value. The ${^CHILD_ERROR_NATIVE} value returns the actual VMS status value and check the severity bits. If the severity bits are equal to 1, then if the numeric value for $? is between 2 and 255 or 0, then $? accurately reflects a value passed back from a Unix application. If $? is 1, and the severity bits indicate a VMS error (2), then $? is from a Unix application exit value.
437 :         Conversely, when setting $? in an END block, an attempt is made to convert the POSIX value into a native status intelligible to the operating system upon exiting Perl. What this boils down to is that setting $? to zero results in the generic success value SS$_NORMAL, and setting $? to a non-zero value results in the generic failure status SS$_ABORT. See also "exit" in perlport.
439 :         With the "PERL_VMS_POSIX_EXIT" logical name defined as "ENABLE", setting $? will cause the new value to be encoded into $^E so that either the original parent or child exit status values 0 to 255 can be automatically recovered by C programs expecting _POSIX_EXIT behavior. If both a parent and a child exit value are non-zero, then it will be assumed that this is actually a VMS native status value to be passed through. The special value of 0xFFFF is almost a NOOP as it will cause the current native VMS status in the C library to become the current native Perl VMS status, and is handled this way as it is known to not be a valid native VMS status value. It is recommend that only values in the range of normal Unix parent or child status numbers, 0 to 255 are used.
441 :         The pragma "use vmsish 'status'" makes $? reflect the actual VMS exit status instead of the default emulation of POSIX status described above. This pragma also disables the conversion of non-zero values to SS$_ABORT when setting $? in an END block (but zero will still be converted to SS$_NORMAL).
perlport.pod
1053 :     system  As an optimization, may not call the command shell specified in $ENV{PERL5SHELL}. "system(1, @args)" spawns an external process and immediately returns its process designator, without waiting for it to terminate. Return value may be used subsequently in "wait" or "waitpid". Failure to spawn() a subprocess is indicated by setting $? to "255 << 8". $? is set in a way compatible with Unix (i.e. the exitstatus of the subprocess is obtained by "$? >> 8", as described in the documentation). (Win32)
1061 :             The return value is POSIX-like (shifted up by 8 bits), which only allows room for a made-up value derived from the severity bits of the native 32-bit condition code (unless overridden by "use vmsish 'status'"). If the native condition code is one that has a POSIX value encoded, the POSIX value will be decoded to extract the expected exit value. For more details see "$?" in perlvms. (VMS)
perlop.pod
1177 :                     if (m?^$?) {
1665 :     A string enclosed by backticks (grave accents) first undergoes double-quote interpolation. It is then interpreted as an external command, and the output of that command is the value of the backtick string, like in a shell. In scalar context, a single string consisting of all output is returned. In list context, a list of values is returned, one per line of output. (You can set $/ to use a different line terminator.) The command is executed each time the pseudo-literal is evaluated. The status value of the command is returned in $? (see perlvar for the interpretation of $?). Unlike in csh, no translation is done on the return data--newlines remain newlines. Unlike in any of the shells, single quotes do not hide variable names in the command from interpretation. To pass a literal dollar-sign through to the shell you need to hide it with a backslash. The generalized form of backticks is "qx//". (Because backticks always undergo shell expansion as well, see perlsec for security concerns.)
perlrun.pod
432 :                  eval '(exit $?0)' && eval 'exec perl -wS $0 ${1+"$@"}'
perlobj.pod
558 :     Because "DESTROY" methods can be called at any time, you should localize any global variables you might update in your "DESTROY". In particular, if you use "eval {}" you should localize $@, and if you use "system" or backticks you should localize $?.
perlmod.pod
154 :     Inside an "END" code block, $? contains the value that the program is going to pass to "exit()". You can modify $? to change the exit value of the program. Beware of changing $? by accident (e.g. by running something via "system").
<< Back to Perldoc Search