lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/08/90)
In <267063fd-6b6comp.sys.amiga.tech@tronsbox.UUCP>, bleys@tronsbox.UUCP (Bill Cavanaugh) writes: >I attempted to use the Lattice "lc" command to compile a file that was in >RAM:. I typed "lc -Lm file.c", and got the message "File RAM:-Lm.c does not >exist. Try again." > >What's the deal? It works with a standard CLI, but not with WShell/ConMan. >Is there some path expanding going on? Is there some way I can turn it off? Works fine for me, using WShell, ConMan, and Lattice C 5.05 Sounds to me like you need to do an 'assign LIB: wherever' to point Lattice at the Lattice lib directory. -larry -- The raytracer of justice recurses slowly, but it renders exceedingly fine. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
bleys@tronsbox.UUCP (Bill Cavanaugh) (06/09/90)
I attempted to use the Lattice "lc" command to compile a file that was in RAM:. I typed "lc -Lm file.c", and got the message "File RAM:-Lm.c does not exist. Try again." What's the deal? It works with a standard CLI, but not with WShell/ConMan. Is there some path expanding going on? Is there some way I can turn it off? /******************************************************************** * All of the above copyright by the below. * * * * Bill Cavanaugh uunet!tronsbox!bleys * * * * "You can only be young once, but you can be immature forever." * * Larry Anderson * ********************************************************************/
rsbx@cbmvax.commodore.com (Raymond S. Brand) (06/09/90)
In article <267063fd-6b6comp.sys.amiga.tech@tronsbox.UUCP>, bleys@tronsbox.UUCP (Bill Cavanaugh) writes: > I attempted to use the Lattice "lc" command to compile a file that was in > RAM:. I typed "lc -Lm file.c", and got the message "File RAM:-Lm.c does not > exist. Try again." > > What's the deal? It works with a standard CLI, but not with WShell/ConMan. > Is there some path expanding going on? Is there some way I can turn it off? The problem is with Lattice (and they've know about it for quite a while now). What is happening is that WShell includes the path with the command name, which in this case is "RAM DISK:"; notice the space between RAM and DISK. When Lattice builds its arg vector it gets the command name from the process or CLI struct (I forget which), appends the arguments from the command line to it, then it parses it. Lattice will have this problem with any command that has a space in the name. For details on how to fix your programs, see below. If you have the latest WShell (don't know what it is, its at work), there is a config option that will turn the path off; look at the docs or call Bill Hawes. To fix your own programs you need to replace the Lattice supplied c.o and _main.o (in lc.lib). Suitable replacements can be found in the RCS distribution (rsbx.lib and its source) or on the latest set of developer disks. rsbx > * Bill Cavanaugh uunet!tronsbox!bleys * ------------------------------------------------------------------------ Raymond S. Brand rsbx@cbmvax.commodore.com Commodore-Amiga Engineering ...!uunet!cbmvax!rsbx 1200 Wilson Drive (215)-431-9100 West Chester PA 19380 "We're working on it" ------------------------------------------------------------------------
bjornk@bula.se (Bjorn Knutsson) (06/09/90)
In article <267063fd-6b6comp.sys.amiga.tech@tronsbox.UUCP> bleys@tronsbox.UUCP (Bill Cavanaugh) writes: >I attempted to use the Lattice "lc" command to compile a file that was in >RAM:. I typed "lc -Lm file.c", and got the message "File RAM:-Lm.c does not >exist. Try again." > >What's the deal? It works with a standard CLI, but not with WShell/ConMan. >Is there some path expanding going on? Is there some way I can turn it off? I belive this is caused by a bug in Lattice startup code. It doesn't like filenames/paths with spaces. You can solve the problems this causes by a) Renaming RAM: to "RAM_DISK" or b) Removing the "pathname" option in your Config-WShell. >/******************************************************************** > * All of the above copyright by the below. * > * * > * Bill Cavanaugh uunet!tronsbox!bleys * > * * > * "You can only be young once, but you can be immature forever." * > * Larry Anderson * > ********************************************************************/ --- Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk Stangholmsbacken 44 / Phone : +46-8-710 7223 S-127 40 SKARHOLMEN / "Oh dear, I think you'll find reality's on the S W E D E N / blink again." -- Marvin The Paranoid Android
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/10/90)
In article <267063fd-6b6comp.sys.amiga.tech@tronsbox.UUCP> (Bill Cavanaugh) writes: >I attempted to use the Lattice "lc" command to compile a file that was in >RAM:. I typed "lc -Lm file.c", and got the message "File RAM:-Lm.c does not >exist. Try again." >What's the deal? It works with a standard CLI, but not with WShell/ConMan. >Is there some path expanding going on? Is there some way I can turn it off? This is the first really bogus bug that Bill Hawes has ever subjected me to. It took me about 3 hours to figure out what the problem was. Basically, in the WSHell update there is a program in rexx: called lc.rexx which is a _silly_ frontend for Lattice C with the same name as the lattice command. It takes all different arguments. (Much wordier ones too) Anyway, either delete it or rename it to something like rexx:boguslc.rexx and that will "solve" your problem. -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"