Xref: utzoo comp.sys.amiga:35187 comp.sys.amiga.tech:5564
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcnc!ecsvax!kms
From: kms@ecsvax.UUCP (Ken Steele)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Lattice LC question (Was "assign problem")
Keywords: looking for lc?'s in all the wrong places
Message-ID: <7146@ecsvax.UUCP>
Date: 10 Jun 89 21:32:00 GMT
Followup-To: comp.sys.amiga
Organization: UNC Educational Computing Service
Lines: 28


It seems that the Lattice LC is not maintaining the correct
directory path to lc1 and lc2.  Here are the symptoms.

lc, lc1, lc2, blink are in L1: (no subdirectory).  Libs and includes
are in L2: (in appropriate subdirectories). LC: is assigned to L1:,
INCLUDE: and LIB: are assigned to L2:, QUAD: is assigned to ram:,
and I added LC: to the search path. The source file is in sys:src.
SYS: is in DF0: and L1: is in DF1:. I then proceed to run the
ever-popular "lc -L sys:src/hello". After the sign-on garbage, I am
asked to insert L2: in ANY drive. If I put L2: in DF0:, then
compilation proceeds (with much-o disk swapping). If I put L2: in
DF1: (removing L1: of course) THEN I get the big screen-flash abort,
with the complaint that "LC2 is unknown command."

It seems as if LC is looking in currently mounted volumes for
LC2 instead of the logical device LC:.  Has any else noted this?

If true, can LC be patched/zapped to look for lc:lc1 and
lc:lc2 _safely_?

Thanks for the help.

                --ken
-- 
Ken Steele   Dept. of Psychology    kms@ecsvax.[bitnet || UUCP]
             Mars Hill College      kms@ecsvax.uncecs.edu
             Mars Hill, NC 28754