FIXCLI

The purpose of this program is to eliminate the trouble one has with starting
up a new CLI (or Shell) from programs like PopCLI, DMouse, MyMenu, and others
which allow you to run NewCLI without an existing CLI.  The trouble is that a
new CLI will be created just fine, but that CLI will have no current
directory and no command path.  If you ask it what the CD is, it will say
"SYS:", but it is actually the root directory of the disk you booted from,
even if SYS: has since been assigned elsewhere.  If you ask the path, it says
"Current Directory" and "C:".  This is actually an empty path.

FixCLI fixes both the path and the current directory in one step.  It is
intended to be placed in a CLI-Startup and/or Shell-Startup script.  It is
"pure" and can be made resident.  If you already have a valid CD and a non-
empty path, then FixCLI has absolutely no effect.

There are two versions of FixCLI.  The smaller and simpler one is a bit over
1k in size.  The fancier one, here called FixCLI-W (just rename it FixCLI if
this is the one you want to use), is over 1.5k in size, and has one extra
feature that many users will never need.  It is for use with CLI windows
created elsewhere than on the Workbench screen, for instance, with "NewShell
CON:S*/etc" using ConMan.  The problem is that system requesters such as
"Please insert" will appear back on the Workbench screen.  FixCLI-W changes
the CLI's WindowPtr value so that such requesters appear on the screen that
the CLI's window is on.

What both versions of FixCLI do is check the current directory, and if it is
zero, it tries to set the current directory to be the directory named in the
command argument line.  For example, "FixCLI ram:" will CD to the ram disk,
unless you have a valid current directory already.  Quotes are not necessary
around a directory name with spaces in it, unless there is a space at one
end.  If you don't name a directory, it CD's to the current SYS:.

It then checks to see if the path is empty, and if it is, it tries to copy
the path known to the Workbench process, which got it from the initial CLI
that ran LoadWB.  If you gave a Path command after the Workbench was already
running, FixCLI won't know about it.  If the Workbench's path is empty or
there is no Workbench, it tries to find another CLI to learn the path from. 
First it looks for the initial CLI, then for a CLI created by NewShell, then
for one made by NewCLI, and as a last resort it looks for a background CLI. 
The copying of the path from another process is much quicker than using an
actual Path command, because it does not read the disk.  

Note that the path aspect is independent of the CD aspect; each can happen
without the other.  It returns 5 (WARN) when it sets either the current
directory or the path.  It returns zero if it does neither.  If it tries to
CD and the directory you name can't be found, it returns 10 (ERROR) and
leaves the path unchanged.  The effect on the WindowPtr value, if FixCLI-W
changes it, is not reflected in the return code.

When it sets the CD according to a command line argument, it copies the text
of that argument into the SetName space.  This is what the Shell uses to show
your current directory in the prompt.  The prompt will show the directory
name as you typed it, not in the official form that the CD command would use.
For example, "CD sys:utilities" might put "Workbench1.3:Utilities" in the
SetName, but FixCLI would just put "sys:utilities".  It saves disk access
to do it this way.  If you want to get the official string in there, you can
give the command CD "" (set current directory to the empty string in quotes).
Or you can just type it properly in the FixCLI command.

In my opinion, a proper s:CLI-Startup file contains exactly two commands:
Prompt and FixCLI.  A proper s:Shell-Startup contains these two plus aliases.

To compile FixCLI-W, #define the name WINDOWPTR.  This can be done with the
Aztec -d option.  I'm not sure if it will compile correctly with Lattice.

FixCLI is in the public domain, by Paul Kienitz.