[comp.sys.atari.st] LHARC problems ....

kgg@zinn.MV.COM (Kenn Goutal) (05/25/90)

So how does one obtain a copy of the ST port of the Unix LHARC
that can be found on dsrgsun?

-- Kenn Goutal

"Ship and travel intermodally;  commute electronically!"

UUCP:	kenn@rr.MV.COM		(...decvax!zinn!rr!kenn)
  or:	kenn@zinn.MV.COM	(...decvax!zinn!kenn)
BIX:	kenn
CompuServe:	71117.2572	(PARTI handle == kenn)
TelePath:	kenn

klute@heike.informatik.uni-dortmund.de (Rainer Klute) (05/25/90)

In article <sent.Wed.May.23.16:59:17.GMT.1990.via.CS.TARDIS>,
olorin@tardis.computer-science.edinburgh.ac.uk writes:
|> There have been one or two postings lately about lharc
|>incompatibilities . The main reason for this is the recently posted
|>lharc 1.13 . Throw it away ! It wont read anything but ST and MS-DOS
|>lharcs ... there are two reasons for this . One is a bug in the header
|>checksum routine which works for MS-DOS but the ST version is totally
|>brain-damaged and assumes an ST header .. if the checksum fails you get
|>the cryptic 'No File' . Secondly even if this bug wasn't there,there is
|>no support for '/' to '\' translation which messes things up somewhat :-)
|>In my experience UNIX lharc will extract anything despite it having a
|>lower version number ... A port of this to the ST is on dsrgsun. Since
|>using that I've never had problems extracting anything . Also it
|>doesn't suffer from the silly file limit of 1.13 , or the annoying 'sort
|>by filename' feature .

Is this common sense? If it is I would like to adopt Arcgsh to it. As I
announced here a week or so ago the new version 3.0 of Arcgsh has a
graphical interface to LHarc - but that's the LHarc version posted in
comp.binaries.atari.st and the above quoted poster suggests to "throw it away".

If you all would rather like to see Arcgsh working together with the
LHarc version on dsrgsun I could adopt Arcgsh to it (a minor task)
before releasing Arcgsh V3.0 to the world. The Arcgsh documentation
isn't ready anyway...

  Dipl.-Inform. Rainer Klute      klute@heike.informatik.uni-dortmund.de
  Univ. Dortmund, IRB             klute@unido.uucp, klute@unido.bitnet
  Postfach 500500         |)|/    ...uunet!unido!klute
D-4600 Dortmund 50        |\|\    Tel.: +49 231 755-4663

kgg@zinn.MV.COM (Kenn Goutal) (05/29/90)

In article <102502@convex.convex.com>, rosenkra@convex1.convex.com (William Rosencranz) writes:

> look: can we please stop using lharc until it works EVERYWHERE?

I can't argue with this.

> zoo is THE standard in the PC world

But (a) I'm not sure I see the relevance of a fact about the PC world
with regard to the ST world, unless you mean it in the pre-IBM sense
of "any personally-owned computer";  and (b) I can't agree with the
statement using the latter interpretation, except for:

> (at least on the net). 

I only just started reading netnews again (after a few years absence),
a few weeks ago, and only this newsgroup, and only here have I heard
of 'zoo'.  I have know about and used uu*code on the net for years,
and have been using plain old ARC between my Atari and this-here Unix
box, between my Atari and BIX and CompuServe, and with friends who
also have Ataris.

This is not to say that we should not advance the art.
If zoo is better than ARC and/or uu*code, I'd like to get it and use it,
although I cringe (well, wince anyway) at the thought of keeping and
using *three* such programs instead of a mere (haha) two.

By the same token, though, I would *really* cringe at having to keep
and use *four* different such packages -- that is, including LHARC --
especially if the latter doesn't work.

I suppose it would be too much to hope that LHARC format will have
some sort of 'format version' field, so that the program can detect
which version wrote a given file -- ARC, LHARC, or some future version --
and read it accordingly.

-- Kenn Goutal

UUCP:	kenn@rr.MV.COM		(...decvax!zinn!rr!kenn)
  or:	kenn@zinn.MV.COM	(...decvax!zinn!kenn)
BIX:	kenn
CompuServe:	71117.2572	(PARTI handle == kenn)
TelePath:	kenn

+-----------------------------------------------------------+
|  Ship and Travel Intermodally -- Commute Electronically!  |
+-----------------------------------------------------------+

klute@heike.informatik.uni-dortmund.de (Rainer Klute) (05/29/90)

In article <2199@laura.UUCP>, I wrote:
|>If you all would rather like to see Arcgsh working together with the
|>LHarc version on dsrgsun I could adopt Arcgsh to it (a minor task)
|>before releasing Arcgsh V3.0 to the world. The Arcgsh documentation
|>isn't ready anyway...

I have got some replies to my posting quoted above suggesting to support
the LHarc version on dsrgsun with Arcgsh. I haven't got any reply that
where against it. So yesterday I did the neccessary modifications to
Arcgsh. I did not test LHarc extensively but the basic features seem to work.

Someone suggested I should send the dsrgsun-LHarc to Steven Grimm to get
it posted to comp.binaries.atari.st. However, I think someone over there
in America should do that. The reason is simple: transatlantic mail is a
little expensive.

The Arcgsh documentation is nearly complete. So Arcgsh V3.0 will leave
Dortmund in the next days to show up in comp.binaries.atari.st really soon now.

  Dipl.-Inform. Rainer Klute      klute@heike.informatik.uni-dortmund.de
  Univ. Dortmund, IRB             klute@unido.uucp, klute@unido.bitnet
  Postfach 500500         |)|/    ...uunet!unido!klute
D-4600 Dortmund 50        |\|\    Tel.: +49 231 755-4663

ralph@laas.fr (Ralph P. Sobek) (06/14/90)

Not that I'm a fan of LHARC, but

In article <sent.Wed.May.23.16:59:17.GMT.1990.via.CS.TARDIS> olorin@tardis.computer-science.edinburgh.ac.uk writes:

|      There have been one or two postings lately about lharc
|     incompatibilities . The main reason for this is the recently posted
|     lharc 1.13 . Throw it away ! It wont read anything but ST and MS-DOS
|     lharcs ... there are two reasons for this . 

The original LHARC that was posted (version 0.73 I believe) was
atrocious!  Since then, I've seen the buggy UNLZH v. 1.11 and the now
better v. 1.14 (numbers might be slightly off, since I'm doing all
this from memory -- sory).  For the moment, the LHARC.TTP (version
1.13 beta) that Steven Grimm posted w/o any coding other than UUE, is
the best working LHARC that I've found on my ST.  In addition, it
seems to be 100 % compatible with our Unix lharc:

C-LHarc for UNIX Version 1.00   (C) 1989-1990 Y.Tagawa, Kai Uwe Rommel

All *.LZH files that've come over the comp.{sources|binaries}.atari.st
newsgroups have been accepted or rejected by both LHARC v.1.13 beta
and C-LHarc v.1.00: lhst113.lzh, minit933.lzh, miniview.lzh,
sambin.lzh, samsrc.lzh, unlzh14.lzh, aua_info.lzh, bbs2903.lzh have
all been accepted.

How come I'm so lucky if others are having such troubles?  It took
awhile for me to get a valid LHARC.TTP, but now I have one that works.
I would wish, though, that someone would improve the syntax.  If
someone is listing or testing an archive, why do file names *have* to
be specified?  ARRGH!

--
Ralph P. Sobek			  Disclaimer: The above ruminations are my own.
ralph@laas.fr				   Addresses are ordered by importance.
ralph@laas.uucp, or ...!uunet!laas!ralph		
If all else fails, try:				      sobek@eclair.Berkeley.EDU
===============================================================================
Reliable software should kill people reliably! -Andy Mickel, Pascal News #13,78

silvert@cs.dal.ca (Bill Silvert) (06/15/90)

In article <RALPH.90Jun14110242@orion.laas.fr> ralph@laas.fr writes:
>the best working LHARC that I've found on my ST.  In addition, it
>seems to be 100 % compatible with our Unix lharc:
>
>C-LHarc for UNIX Version 1.00   (C) 1989-1990 Y.Tagawa, Kai Uwe Rommel
>
>How come I'm so lucky if others are having such troubles?  It took
>awhile for me to get a valid LHARC.TTP, but now I have one that works.

There are several flavours of Unix.  I was able to compile LHARC on
4.3BSD with fair success, but under System V I can't get it going.
You may simply have the right Unix.


-- 
William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2.  Tel. (902)426-1577
UUCP=..!{uunet|watmath}!dalcs!biomel!bill
BITNET=bill%biomel%dalcs@dalac	InterNet=bill%biomel@cs.dal.ca