Compress command incompatable on Xenix 2.3.4
Bela Lubkin
> I ran across an odd compatability problem... I did a 'compress' on a
> file on an AIX (RS6000) system and did a 'tar' to a diskette and copied
> it to a SCO Xenix 2.3.4 system. When I tried to 'uncompress' the file I
> got an error, Can't uncompress a 16 bit file on a 12 bit system.
The compress/uncompress programs that come with XENIX 2.3.4 do support
16-bit compression. You must somehow have gotten an old '286 binary
onto your system. Look at the file dates on /usr/bin/compress vs. other
programs in the same directory -- was it installed at the same time? Is
there a /bin/compress on your system, earlier on the PATH than /usr/bin,
which is an old 286 version? Run file(C) on whatever compress binaries
you find, see what kind of executables they are.
Yes, the binary from XENIX 2.3.2 will work fine on your 2.3.4 system.
>Bela<
Note that SCO Unix traffic is migrating to the new newsgroups
comp.unix.sco.{misc,programmer,announce}. I've crossposted this and set
followups to use the appropriate new group.
mitchel rucko
file on an AIX (RS6000) system and did a 'tar' to a diskette and copied
it to a SCO Xenix 2.3.4 system. When I tried to 'uncompress' the file I
got an error, Can't uncompress a 16 bit file on a 12 bit system.
I never heard of this error!!
The same thing happened when I compressed a file on Xenix 2.3.2 and on
UNIX 3.2.4. When I compressed the file on Xenix 2.3.4, the resulting
'.Z' file was about twice as big!
Is this documented? Is there a fix (can I copy the compress and
uncompress from 2.3.2 to 2.3.4?)
Thanks in advance for your help.
Mitchell Rucko
Medix, Inc.
33 Washington Street
Newark, NJ 07201-3079
+1-201-648-0019 Ext.: 149
Bill Davidsen
| I ran across an odd compatability problem... I did a 'compress' on a
| file on an AIX (RS6000) system and did a 'tar' to a diskette and copied
| it to a SCO Xenix 2.3.4 system. When I tried to 'uncompress' the file I
| got an error, Can't uncompress a 16 bit file on a 12 bit system.
First, you have an old version of compress which only does 12 bit data.
You should upgrade to a version compiled for full functionality. This
was possible even on Xenix286, so a modern 32 bit system is fine. I can
send you the binary, and maybe even find the source.
Second, you should really think about getting gzip for all your systems,
since it's better at compression, almost as fast at low levels of
compression, and available in source.
When making files for 12 bit limited systems you can use the "-b12"
option to compress, but hardly anyone has this problem anymore.
--
I do not pick my enemies based on race, religion, gender, education,
dietary preferences, social or financial status or country of origin.
These rules apply to choosing my friends as well...
Kirk B. Spadt
>I ran across an odd compatability problem... I did a 'compress' on a
>file on an AIX (RS6000) system and did a 'tar' to a diskette and copied
>it to a SCO Xenix 2.3.4 system. When I tried to 'uncompress' the file I
>got an error, Can't uncompress a 16 bit file on a 12 bit system.
>Is this documented? Is there a fix (can I copy the compress and
>uncompress from 2.3.2 to 2.3.4?)
Try:
compress -b 12 rs6000file
This limits the number of bits used to compress the file to 12, for
compatibility with older systems. This should enable uncompress to work on
any system.
Limiting the number of bits to 12 also causes the compressed file to be
larger, which you observed when compressing on xenix 2.3.2. I would
guess that the reason xenix 2.3.2 uses only 12 bits is to use less system
resources. Smaller hash tables and less cpu cycles are needed to execute the
compression algorithm.
Hope this helps.
Kirk
------------------------------------------------
Kirk B. Spadt ksp...@keyware.com
Keyware Systems, Inc.
570 Lindsey Drive (610) 964-9530
Radnor, PA 19087 (610) 964-0543 fax
Jeffrey D. Angus
> compress -b 12 rs6000file
>
> This limits the number of bits used to compress the file to 12, for
> compatibility with older systems. This should enable uncompress to work on
> any system.
This also makes compress with most versions of MS-DOS compress floating
around.
--
"Ideas are more powerful than guns. We would not let our enemies have
guns, why should we let them have ideas." -- Joseph Stalin
Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM Internet: jan...@skyld.grendel.com
US Mail: PO Box 4425 Carson, CA 90749 Phone: 1 (310) 324-6080
Stephen M. Dunn
$file on an AIX (RS6000) system and did a 'tar' to a diskette and copied
$it to a SCO Xenix 2.3.4 system. When I tried to 'uncompress' the file I
$got an error, Can't uncompress a 16 bit file on a 12 bit system.
$
$I never heard of this error!!
I have, but there's no way you should have received it.
The Xenix-286 version of compress compresses using 12 bits,
as the 64 kB segment size limit tends to cause problems with this
algorithm. However, there's no such thing as Xenix-286 2.3.4, AFAIK,
and so you're running a 386 version. All SCO *ix-386 versions of
compress, by default, work to the full 16 bits, though you can
manually decrease this (for compatibility with less capable
versions) with the -b switch.
Somehow, you've managed to get a Xenix-286 version of
uncompress on your machine. Grab the diskettes and reinstall
the right one (grep through /etc/perms for it ... on 2.3.3, at
least, it's in /etc/perms/ext) and this problem should go away.
$The same thing happened when I compressed a file on Xenix 2.3.2 and on
$UNIX 3.2.4. When I compressed the file on Xenix 2.3.4, the resulting
$'.Z' file was about twice as big!
Since compress, uncompress, and zcat are all the same binary,
you'd have the same problem with all three. Your Unix version,
on the other hand, would be using the full 16 bits. If you
specified -H as well, your Unix version would be using the
higher-compression LZH algorithm, yielding further compression
(but at the loss of compatibility with standard compress
utilities).
================================================================
Note that the biz.sco hierarchy is in the process of being
superseded by the comp.unix.sco hierarchy. I have crossposted
this article into the new hierarchy, and followups are directed
there.
================================================================
--
ste...@bokonon.UUCP ...!{xrtll,gts.org}!bokonon!stephen
----------------------------------------------------------------------------
Stephen M. Dunn, CNE, ACE, Sr. Systems Analyst, United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7 (416) 750-7946 x251