Re: [opensuse] Missing compress in SUSE10?
I need to use the old fashioned UNIX "compress" for some apps I work with. Since I've updated to SUSE 10 (on Friday last week), I haven't been able to find it... I have the man page for compress, but the compress binary is missing from /usr/bin.
Have I completely missed the obvious here? I can't find compress on the DVD, on the SUSE ftp site, on the APT repositories.
I can use a workaround - ie by editing certain install scripts and pointing uncompress to zcat, or compiling my own copy of comress, but that doesn't solve the core problem that compress/uncompress is missing - or at least I can't find it.
I need to use compress to maintain multi-Unix platform compatibility win an app that the department creates... I can't guarantee that alternative such as gzip (for example) are available in Solaris, AIX etc. But... normally compress is everywhere... except in SUSE 10?
Any suggestions?
I'm not sure, but i thought that gzip can handle compressed files.... Stephan
I'm not sure, but i thought that gzip can handle compressed files....
Yes gzip can handle it, but that doesn't solve my core problem. I work at a software company and we make software that runs on Linux as well as pretty much all other flavours of Linux. We use compress/uncompress to extract and install the software - the call to uncompress is part of the install shell script. Problem is, gziup isn't available on all Unix platforms - whereas compress is. I installed SUSE 10.0 on Friday... today I try a test install of our software, and.. it fails because uncompress isn't there. Like I said, I can hack the installer to use zcat (gzip) and it all works... but that's a single instance hack... and doesn't help anyone else who might try to install on SUSE 10. So... that still leaves me with the question... what happened to that old fashioned compress/uncompress app? I'm wondering if I missed it in the installer... or if it was dropped. C.
On Mon, Oct 24, 2005 at 03:55:55PM +0200, Clayton wrote:
I'm not sure, but i thought that gzip can handle compressed files....
Yes gzip can handle it, but that doesn't solve my core problem. I work at a software company and we make software that runs on Linux as well as pretty much all other flavours of Linux. We use compress/uncompress to extract and install the software - the call to uncompress is part of the install shell script. Problem is, gziup isn't available on all Unix platforms - whereas compress is.
I installed SUSE 10.0 on Friday... today I try a test install of our software, and.. it fails because uncompress isn't there. Like I said, I can hack the installer to use zcat (gzip) and it all works... but that's a single instance hack... and doesn't help anyone else who might try to install on SUSE 10.
So... that still leaves me with the question... what happened to that old fashioned compress/uncompress app? I'm wondering if I missed it in the installer... or if it was dropped.
It had patent problems as Unisys was still owning the LZW patent. I think it the patent expired now. For SLES 9 we include "ncompress" now which contains compress/uncompress. If you just need uncompress you really can just provide a symlink. If you need the original compress you have to find the ncompress package. Ciao, Marcus
Clayton wrote:
I installed SUSE 10.0 on Friday... today I try a test install of our software, and.. it fails because uncompress isn't there. Like I said, I can hack the installer to use zcat (gzip) and it all works... but that's a single instance hack... and doesn't help anyone else who might try to install on SUSE 10.
Couldn't the installer check for the existence of uncompress and use zcat if uncompress did not exist and so on until it finally gave a warning that it could not find the correct tools to install? -- Guðlaugur Jóhannesson http://www.hi.is/~gudlaugu Phone: +354 849 8405
Couldn't the installer check for the existence of uncompress and use zcat if uncompress did not exist and so on until it finally gave a warning that it could not find the correct tools to install?
Yes it could, and ultimately this will probably be the solution we implement. I need to be sure I'm not having finger problems before someone cracks open the installer script and starts tinkering. As it is with all software, if you change something, something else might break or not work exactly the way you expect... the installer is working fine right now... I guess it's a simple case of me not understanding why it works fine in my previous 9.3 install (in all our 9.3 installs actually) and not in 10.0... why I see a man page for compress, but the app itself is not there where I expect it in 10.0 (in /usr/bin ). C.
Clayton wrote:
in 10.0... why I see a man page for compress, but the app itself is not there where I expect it in 10.0 (in /usr/bin ).
The man-page is part of man-pages-2.07-1, and even back in 9.0, compress was just a symlink to compress-dummy.sh, a script which uses gzip for uncompressing files. That script is still there in 10.0RC1 (part of sharutils-4.5-2), but the symlink is gone. /Per Jessen, Zürich -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Sign up for your free 30-day trial now!
The man-page is part of man-pages-2.07-1, and even back in 9.0, compress was just a symlink to compress-dummy.sh, a script which uses gzip for uncompressing files. That script is still there in 10.0RC1 (part of sharutils-4.5-2), but the symlink is gone.
Ahhh... that makes sense. I found compress-dummy.sh, but... didn't look deep enough into it. That's exactly what I needed to know. Thanks! C.
Per, On Monday 24 October 2005 10:32, Per Jessen wrote:
Clayton wrote:
in 10.0... why I see a man page for compress, but the app itself is not there where I expect it in 10.0 (in /usr/bin ).
The man-page is part of man-pages-2.07-1, and even back in 9.0, compress was just a symlink to compress-dummy.sh, a script which uses gzip for uncompressing files. That script is still there in 10.0RC1 (part of sharutils-4.5-2), but the symlink is gone.
Odd. On my system (10.0) the substitution script is /usr/bin/compress-dummy (no ".sh" suffix). If it mattered to me, I'd probably just put a symlink in my ~/bin directory. Since I make no use of compress, it doesn't (matter) and I was unaware of the gap until this topic came up here.
/Per Jessen, Zürich
Randall Schulz
Randall R Schulz wrote:
Odd. On my system (10.0) the substitution script is /usr/bin/compress-dummy (no ".sh" suffix).
Yep, you're right - the .sh suffix is gone in 10.0.
If it mattered to me, I'd probably just put a symlink in my ~/bin directory.
Or even straight into /usr/bin. It seems odd that the script is there, but the symlink isn't. /Per Jessen, Zürich
Per, On Monday 24 October 2005 23:27, Per Jessen wrote:
Randall R Schulz wrote:
...
If it mattered to me, I'd probably just put a symlink in my ~/bin directory.
Or even straight into /usr/bin. It seems odd that the script is there, but the symlink isn't.
It could be an oversight. It's especially odd that the man page is there but the symlink is not. As to putting the symlink into a central bin directory, I don't like altering the system itself.
/Per Jessen, Zürich
Randall Schulz
On Mon, Oct 24, 2005 at 11:33:39PM -0700, Randall R Schulz wrote:
On Monday 24 October 2005 23:27, Per Jessen wrote:
Randall R Schulz wrote:
...
If it mattered to me, I'd probably just put a symlink in my ~/bin directory.
Or even straight into /usr/bin. It seems odd that the script is there, but the symlink isn't.
As to putting the symlink into a central bin directory, I don't like altering the system itself.
I think the ideologically correct place for the symlink would be in /usr/local/bin, since you created the symlink yourself and it was not put there by the system(-vendor). Rasmus
On Tuesday 25 October 2005 01:06, Rasmus Plewe wrote:
...
If it mattered to me, I'd probably just put a symlink in my ~/bin directory.
Or even straight into /usr/bin. It seems odd that the script is there, but the symlink isn't.
As to putting the symlink into a central bin directory, I don't like altering the system itself.
I think the ideologically correct place for the symlink would be in /usr/local/bin, since you created the symlink yourself and it was not put there by the system(-vendor).
Yes, that's probably best.
Rasmus
RRS
participants (7)
-
Clayton -
Guðlaugur Jóhannesson -
Marcus Meissner -
Per Jessen -
Randall R Schulz -
Rasmus Plewe -
Stephan Böni