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:
on my linux machine, I get:strace -f perl5.6.1 -le '`gzrip`; print $?'
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.
In reply to Re: gzip command always returns -1
by thospel
in thread gzip command always returns -1
by jyoshv
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |