rac@sherpa.UUCP (Roger Cornelius) (08/23/90)
Has anyone else noticed that the tar command distributed with SCO UNIX has been hacked to allow magical decompression of compressed files in an archive. At least some of the distribution floppies (5 1/4" anyway) for the version 2 upgrade contain compressed files (sans trailing .Z). The extraction phase somehow senses the files are compressed and pipes them through compress with a -P option. Try moving compress out of your path and then extracting files from the upgrade floppies with tar. You should see an "execl: No such file or directory" error. These changes also exist in the version 1 release. The unfortunate thing about the changes to both tar and compress (new -P flag) is they didn't bother to document them. -- Roger A. Cornelius rac@sherpa.UUCP uunet!sherpa!rac
tneff@bfmny0.BFM.COM (Tom Neff) (08/23/90)
In article <307@sherpa.UUCP> rac@sherpa.UUCP (Roger Cornelius) writes: >The extraction phase somehow senses the files are compressed The standard way to do this is to check for 0x1f 0x9d at the start of file. Dump some .Z's some time... -- When considering "victim's rights," remember || vv Tom Neff that an innocent defendant is also a victim. ^^ || tneff@bfmny0.BFM.COM
rac@sherpa.UUCP (Roger Cornelius) (08/24/90)
From article <15784@bfmny0.BFM.COM>, by tneff@bfmny0.BFM.COM (Tom Neff): > In article <307@sherpa.UUCP> rac@sherpa.UUCP (Roger Cornelius) writes: >>The extraction phase somehow senses the files are compressed > > The standard way to do this is to check for > > 0x1f 0x9d > > at the start of file. Dump some .Z's some time... I have. The third byte into the file will also tell you if it was compressed with 12, 13, ..., 16 bits. The point of the article was not how to read the compress program's magic numbers, it was that SCO has hacked tar and compress without bothering to document the changes. -- Roger A. Cornelius rac@sherpa.UUCP uunet!sherpa!rac