jmeissen@ogicse.ogi.edu (John Meissen) (09/14/90)
In article <13027@june.cs.washington.edu> dylan@june.cs.washington.edu (Dylan McNamee) writes: > >SAS/C 5.10 is indeed neat. I can't get it to compile from the >workbench, though. When I click on build, LMK shows up, and >tries to run lc, which it can't find. The lc: directory is on >my path. Any ideas, or should I not even bother with workbench The execution path is not a global parameter. It is part of a particular CLI run-time environment (not to be confused with environment variables), and is unique to that CLI and its child processes. If a child process changes its path, the changed path is effective from that point down. Workbench is in effect a CLI process, as it is spawned from the first CLI. It has attached to its process structure a copy of the path that was in effect at the time it was spawned. However, the tasks created by Workbench don't have the complete CLI environment, and in particular don't inherit any path information. Whenever I wrote a program that needed to search the path, I looked first for a local copy, and if there was none I then looked for the Workbench task and used whatever path it had. In fact, this is how the forkl() command I wrote for the Lattice compiler (sorry, SAS/C) worked. Whether or not SAS used this approach for LMK, I don't know. In any case, this brings up two points: For Workbench to be aware of the path you set up you have to set it up before invoking Workbench. A Workbench program may not be able to take advantage of a path anyway. Try assigning LC: to the directory with the compiler. -- John Meissen .............................. Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes