🚀 go-pugleaf

I have been using the Micro C-Shell (v2.61) for a few months now and
for the most part agree with the previous comments about it.  It is
a good product and is worth the cost.  The features closely mimic
the features found on the "real" computers at work, so it is easy to
get it to do what you are familiar with in more sophisticated
environments.

One aspect that I do not like very much is that it has does not
very well handle the initiation of GEM programs.  As long as you
are executing TOS or TTP programs (i.e. ASCII terminal oriented),
all is fine.  In order to run GEM programs, you must issue the
command in the form:

	gem <command-name>

The shell seems not to want to look for .PRG files when it is looking
for commands and will not, on its own, perform the setup required for
the GEM program to operate.  It would seem that the gem command was
added as an afterthought for ST use.  Making the user select explicitly
which programs will be run with the mouse and stuff makes it easier for
the shell.

Not intuitively obvious is the fact that command-line arguments are
NOT supported.  Not a BIG deal, but it means that I do not immediately
have the ability to call my Megamax editor with the names of files
to be editted.  Annoying, but fairly easy to work around.

To solve the problem, I wrote myself a program called "gemrun.tos".
It operates seemingly identically to the gem function of the shell,
but additionally passes the arguments to the system when doing
the EXEC.  Of course, it must be read fron the disk, so it is a bit
slower (on floppies) than the standard function that it replaces.

Another anomaly I have found is in the handling of the "no match"
situation on wildcard file specifications.  Unlike the true csh
which will eliminate the pttern word that has no match, Micro C Shell
is more like the Bourne Shell in that it leaves the unsubstituted
pattern word in the argument list.