in reply to gzip command always returns -1

Unfortunately the most relevant fact for this thread is missing from the docs for $?: the description of the bit pattern is only valid if the program actually got started. If even starting the program failed, the returncode will be -1 and in that case looking at the exact bitpattern is pointless.

So the first thing to check in this case is if gzip is avaialable at all as an executable program for the user you are running this as, and what the current PATH setting is if so. But if this is indeed the cause, you should actually also have gotten warning about that from perl too, which you would undoubtedly have seen and solved.

This kind of problem is often best debugged by using strace or an equivalent program (like truss). E.g. if i do:

strace -f perl5.6.1 -le '`gzrip`; print $?'
on my linux machine, I get:
execve("/usr/bin/perl5.6.1", "perl5.6.1", "-le", "`gzrip`; print $?", /* 134 vars */) = 0
...
pipe(3, 4)                            = 0
pipe(5, 6)                            = 0
fork(Process 27193 attached
)                                  = 27193
...
pid 27192 close(4)                    = 0
pid 27192 close(6)                    = 0
...
pid 27193 execve("/usr/local/bin/gzrip", "gzrip", /* 134 vars */) = -1 ENOENT (No such file or directory)
...
pid 27193 execve("/sbin/gzrip", "gzrip", /* 134 vars */) = -1 ENOENT (No such file or directory)
...
pid 27193 execve("./gzrip", "gzrip", /* 134 vars */) = -1 ENOENT (No such file or directory)
...
pid 27193 exit_group(1)               = ?
Process 27193 detached
...
write(1, "-1\n", 3-1
)                     = 3
rt_sigprocmask(SIG_SETMASK, RTMIN, NULL, 8) = 0
munmap(0xb7fe9000, 4096)                = 0
exit_group(0)
(The -f option causes it to follow forks). So you can see:
 - perl starts up
 - perl sets up pipes and forks for the ``
 - In the child it tries the entries in my PATH to start up gzrip,
   but all of them fail
 - The child returns.
 - Perl prints $?, being -1

PS: I advise using the list form of system instead of ``, though I don't expect that to solve your problem. It's still better though, no pointless result pipes, no pointless shell, which *might* be the problem.