rmeyers@tle.dec.com (Randy Meyers 381-2743 ZKO2-3/N30) (06/30/88)
Recently someone asked why CLIs created using POPCLI do not have their
path set up. The reason is given in a message I posted a while back:
Newsgroups: comp.sys.amiga
Path: decwrl!tle.dec.com!rmeyers
Subject: POPCLI 3 doesnot pass PATH
Posted: 22 Feb 88 20:05:23 GMT
Organization: Digital Equipment Corporation
This is my second try at getting through.
decwrl!ucbvax!husc6!ut-sally!mothra!bryan noticed that the CLI command
path is not inherited by new CLIs started by POPCLI 3. This is true,
and it represents a major defect in POPCLI 3. POPCLI 2 does not have
this problem. I strongly recommend that it be used instead of POPCLI 3.
To understand why POPCLI 3 doesn't work, and to understand how to properly
set up your path for POPCLI 2, some background on the Amiga process
structure is needed.
The Amiga has three types of processes: tasks, processes, and CLI processes.
A task is the simplest of the three, and has the least information about
its state stored by the operating system. Its process structure is a
truncated version of the process data structure. The process has enough
information maintained about its state that it can call any AmigaDOS
function. The CLI process is a normal process with its process structure
pointing to some additional information that maintains all the additional
information about a CLI. This information includes the command path,
the prompt string, the CLI's own standard input and output files, the
stack size to use when running commands, etc.
Anyway, when a CLI processes creates another CLI process, the child CLI
inherits the parent CLI's command path, prompt string, current directory,
FAILAT value, and command stack size. After the child CLI is created,
it becomes an independent entity, and its CLI specific information may
diverge from that of its parent.
There are two ways for a CLI to create a new CLI. One is using the NEWCLI
command; the other is use the RUN command. The RUN command creates a new
CLI and runs a particular program it it. An apparent third way, the
AmigaDOS Execute() function, really is a special case of using the RUN
command to create a new CLI process.
POPCLI 2 was a "normal" program. Like all normal programs it ran in the
environment of the CLI that called it (the CLI created by the RUN command).
POPCLI 3 uses Lattice's new cback startup module. This module causes the
program to clone a copy of itself into a normal process. The original
version of the clone then returns to the CLI that called it. Lattice
advertises this ability as the way to "RUN" a program without having to
type the "RUN" command. They are right except for one point: the cloned
program is running in a normal process not a CLI process. That means
that any CLIs created from that process will not inherit a command
path, prompt string, FAILAT code, etc. QED, as they say in this
newsgroup.
So the best way to have your CLIs created by POPCLI properly set up is
and to set up the state of your original CLI before RUNning POPCLI 2.
By the way, Commodore has gimmicked the Workbench to copy when it started
the command path of the CLI that did the LOADWB. Through magic, when you
click on the CLI icon in Workbench, Workbench manages to pass this command
path to the child CLI. However, it does not propagate any of the other
information like prompt string, current directory, FAILAT level, or stack
size.
Suggestion to Commodore-Amiga! Why not do the complete job? I know of
at least one user who was disappointed that the Workbench didn't propagate
his pretty prompt string.
----------------------------------------
Randy Meyers, not representing Digital Equipment Corporation
USENET: {decwrl|decvax|decuac}!tle.dec.com!rmeyers
ARPA: rmeyers%tle.dec.com@decwrl.dec.com