Well 16 777 215 in decimal is 0x00FF 0xFFFF in hex which at first looks like -1 (in 2's complement form) (if you have 24 bit words) but I assume you probably have 32 bit words. Anyway the exit code should only be 8 bits long (in Linux anyway, your system *might* be different) so I don't know where the number 16777215 is coming from offhand.
Update: added the hex printf lines to show how the the 32-bit -1 get's shifted 8 bits and becomes a 24-bit -1.
Try this program out and see what you get:
#!/usr/bin/perl -w
use strict;
my $raw_ret;
print "'true':\n";
`true`;
$raw_ret = $?;
printf("0x%08X\n", $raw_ret);
print $raw_ret; print "\n";
print $raw_ret >> 8; print "\n";
print (($raw_ret >> 8) & 0xFF); print "\n";
print "\n";
print "'false':\n";
`false`;
$raw_ret = $?;
printf("0x%08X\n", $raw_ret);
print $raw_ret; print "\n";
print $raw_ret >> 8; print "\n";
print (($raw_ret >> 8) & 0xFF); print "\n";
print "\n";
print "'nosuchprogramname':\n";
`nosuchprogramname`;
$raw_ret = $?;
printf("0x%08X\n", $raw_ret);
print $raw_ret; print "\n";
print $raw_ret >> 8; print "\n";
print (($raw_ret >> 8) & 0xFF); print "\n";
print "\n";
I get this output:
[frink@truth ~/code/perl]$./ret-code.pl
'true':
0x00000000
0
0
0
'false':
0x00000100
256
1
1
'nosuchprogramname':
Can't exec "nosuchprogramname": No such file or directory at ./ret-cod
+e.pl line 26.
0xFFFFFFFF
-1
16777215
255
I don't think your system can find "gzip" in it's search path. Either that or there is some other reason it can't execut "gzip". Try using the full path to the gzip program in your command. (To find the path use "which gzip" or "whereis gzip" or even "locate gzip" from a command line.)
|