Compress & Uncompress commands ...

[Shahbaz_1]

Hi Friends,
I am looking at the various, compress and uncompress commands available in HP-Ux.
And the difference between them?

How much % "COMPRESS" command compresses a file?

I down loaded a "Oraclesoftware" compressed file, in the following form
"hpux_ipf_90101.cpio.gz "

first I downloaded the above file to DOS, and then FTPed it to Unix in binary mode.
but in Unix when I tried to use gunzip , it says the file is not in zip format.

How should I unzip the above file.

Please ...

Regards
Shah

[sven verhaegen]

Hi , how much % depends entirely on the type of dat you are compressing , normall ASCII tekst could go way up , 50% even but somthing like compressed data will only allow 0.5% extra compression so it is really had to tel you an exact answer , concerning the file you down loaded , is should work with gunzip , however as you stated that you first got the file trough a DOS machine I have a small remark , is say you ftp'ed to the hp9000 in binary mode (which is standard) but did you specify on the dos machine when FTP'ing the file in that needed to be binary mode ?? , i say this because most PC's have a tendency to go for ASCII mode and zipped files can get corrupted then , gunzip would then be unable to read and identify the header and discard the file as being not zipped.. jsut my personal feeling

[Chris Wilshaw]

As Sven says, the compression rate is data dependant.

From experience with compress/gzip, I would say that there's very little difference in actual compression rates between the two (I've rarely seen a difference of more than a few dozen bytes on 1MB files).

gzip is capable of handling files created by compress, zip and pack, and has the added benefit of being able to carry out some error checking on the .Z files (which compress/uncompress do not do).

Another possibility for the corrupt gzip file is that the original download terminated abnormally, leaving you with an incomplete file.

[T G Manikandan]

probably the file downloaded was incomplete.

Try downloading again.
do a gunzip on them

#/usr/contrib/bin/gunzip "file-name"
#cpio -icvmd < "filename.cpio"


Thanks

[Steve Lewis]

I recommend you look at bzip2 for the best compression, short of a heavy statistical algorithm. The home page is at:

http://sources.redhat.com/bzip2/

It is slightly better than gzip,
which is better than compress
which is better than pack and compact.

[Shahbaz_1]

Thanks Sven,

when I copied back from pc to unix, using ftp.
I set the mode in ftp as "bi".

The transfer of file was ok. but when I try ti gunzip the the same file. it says not in gzip format.

should I down the file again?

or ...

please ..

Regards
Shah

[T G Manikandan]

Shabaz,

yes you have to download the file again.
If you use utilities like download accelerator to download the file quickly.
Oracle downloads are bigger in size.

[sven verhaegen]

yes download it again , the problem could arrise when downloading from inetrnet to a PC because as said PC's have a tendence to not setting binary in the first place when ftp'ing so corruption comes from the first download , if that doesn't work I'm just as puzzled as you , unless they used a wrong extention .gzip....

[Arockia Jegan]

Shah,

Can you run the following command in the unix system and post the output of that?.

#file hpux_ipf_90101.cpio.gz

[Joseph C. Denman]

Shahbaz,

gzip by far give you better compression than compress.

As far as unzipping the file, as stated above, I believe the problem lies in the download. Try downloading the file again. You can check the download on the pc. Winzip should be able to open the file. If Winzip can't, the file was not downloaded correctly.

Hope this helps,

...jcd...

[Martin Johnson]

Compare the file sizes of the before the transfer, on the PC and finally on the Unix box. The sizes should be the same.

Also on the unix boes do a cksum. The check sums should be the same. If not, there is a problem with the transfer.

HTH
Marty