[LA.pm] calling gzip from within perl

[Peter Benjamin]

At 02:42 PM 6/29/2005, David Heayn wrote:
>However, when I took it over to another server the script didn't want 
>to fully run. It printed a header and HTML title info, but the "data 
>table" was empty. This secondary server I'm futzing with doesn't 
>allow shell access or ssh'ing into any directories. Could this be the 
>reason it doesn't work?  

No.  But the pathname to the gunzip might be wrong.
That is $PATH does not include it.  Ask the webhost
what the full pathname is to gunzip and use that instead.

$pathGunzip = "/usr/bin/local/gunzip";
...
open ( FH, "$pathGunzip -c |" )...


>I know that some of the compressed files are 
>corrupt. Does the
>die "Can't gunzip $fileLoc...
>line test to see if there is a failed decompression attempt?

No, but one of my posts shows you how to test STDERR via back tics
to 'see' the messages.  The STDERR within an open() can not be
captured.  Back tics I have found are best for this.

Alternatively, the return code of gunzip is either 1 or 0,
indicating good or fail (not sure which is which).  See the
man pages for more info.

I have come to dislike using open pipes for anything but
sending email via sendmail, which I find works fine all the time.
Other times I have used an open pipe, I found troubleshooting
the command required writing a special CGI to view the problem
with backtics, or I wrote a CGI that gave me the equivalent
of shell access, when ssh was not available.

Thus, now I always use backtics and capture the output, so
the CGI can echo it out, if even in html comments so it
is not visible.  Easy debugging that way.  Just view source.