🚀 go-pugleaf

In article <H.eg.r1JSayXXHQc@nathan.do.open.de> ue@nathan.do.open.de writes:
>In <1993Jan2.181513.4659@csi.uottawa.ca>, Christopher Browne writes:
>
>Hi,
>
>>I never use it for anything other than file extraction, so I don't
>>know all of the inter-version compatibility features.  
>I'm using a little bit more, I do all my archiving stuff with LHArc.
>I'm connected to several German file networks for the atari and we do
>not have any problems with incompatible files. The traffic is a little
>bigger than c.[bs].a.s, almost everything is packed with lzh. No problems
>here...
>
>[thought: compatibility mode]
>>Is lharc an exception to this rule?  
>No, just add -o to the command line to create old archives. 

Good to hear.

>But I don't see
>any sense in it: If your 20 year old TV set is broken, there is almost no
>chance to get any replacement parts. Now imagine you would go out and tell
>all company producing TV sets: "Hey, I want you to produce my 20 year old
>TV set so I can get replacement parts!". Thats nonsens, isn't it. You will
>have to buy a new one. 

I'm not suggesting that EVERYTHING get packed using the -o option - just
the archives containing newer versions of LHARC.

If I'm downloading an archive containing LHARC, it's because I don't
have the latest edition, and need a newer one.  'Twould be nice to be
able to use ANY old version of LHARC to extract the new version.  It's
highly annoying to have to download version J in order to extract
version K in order to extract version L.

>>- Lharc
>>There's lots of work going into maintaining/improving Lharc, but
>>unfortunately, it's all quite jumbled, and it's almost impossible to
>>guarantee that you've got a compatible version.  It's fairly fast, but
>>that's because it gets hacked on a lot, which makes it less
>>trustworthy.
>That is -excuse me- complete nonsense. The current LHArc 2.01l package
>is all you need. [SHOUTING ON] IF ANYBODY DISCOVERS AN ARCHIVE S/HE THINKS
>IS "INCOMPATIBLE", SEND A MAIL TO ME. [SHOUTING OFF] I'll show you that this
>is not true. 

Unfortunately, there seems to be separate groups of people working on
versions for varying platforms.

The ATARI LHarc series may be fairly compatible from edition to
edition, but is it 100% compatible with the IBM versions?  It's been a
while since I've done porting work back/forth, but I've always needed
to keep several versions of Lharc/LHA around on both machines.  One
thing that is EXTREMELY annoying is the fact that a Unix port wasn't
available until 1992.

>>- ARC 
>>It's occasionally needed for compatibility with OLD archives.
>>Unfortunately, it's fairly slow, doesn't compress nearly as well as
>>the competition, and the support for subdirectories is a little
>>spotty.
>Hmm, how whould you define the support for subdirectories in zoo? Ever
>tried to create a zoo archive concerning a big directory tree under
>plain tos (no shell, no external programs, just zoo.ttp?) GRIN
>/s/

You're actually asking a different question.  "How would you define
the support required from the CLI in zoo?"  Yes, for some commands,
zoo requires something to go between it and the desktop.  However, any
time I run it from the desktop, I do it via one of the shells.
Usually ZooShell.  More commonly, I'm running tcsh.  The only things
that I DO run from the desktop are "shells" of sorts.

-- 
Christopher Browne                |     PGP 2.0 key available
cbbrowne@csi.uottawa.ca           |======================================
University of Ottawa              | Genius may have its limitations, but
Master of System Science Program  | stupidity is not thus handicapped.