rmeyers@tle.dec.com (Randy Meyers 381-2743 ZKO2-3/N30) (02/19/88)
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.
(POPCLI 2 is available on Fish disk 40.)
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 create 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.comdrs-ano@duvan.nada.kth.se (Gunnar Nordmark) (03/02/88)
In article <8802182204.AA18542@decwrl.dec.com> rmeyers@tle.dec.com (Randy Meyers 381-2743 ZKO2-3/N30) writes: >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. >(POPCLI 2 is available on Fish disk 40.) > >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. > I use a 'login' file that sets up the environment I want whenever I pop up a new CLI. It works great with PopCLI III. I have this line in my Startup-Sequence: PopCLI 300 NewCLI >NIL: "CON:0/0/640/256/AmigaDOS ARP" S:.login The script file .login is executed when the new CLI pops up and it initializes the Path and everything else one can imagine. You can add a call to the DOS command Date to the .login file. Now when you pop up the new CLI you'll get something like: New CLI task 2 Tuesday 01-Mar-88 21:52:44 2> Nice isn't it? Personally I like the idea of a command that says 'POP!' added to my .login file :-) --- SNAIL: Gunnar Nordmark VOICE: 08 - 755 42 52 Nora strand 5 S-182 34 DANDERYD EMAIL: nordmark@epsilon.stacken.kth.se SWEDEN