This is a response to Ron Bardarson on Z-Node
Central, part of a discussion we have been having
regarding the implementation of WordStar 4.0 as a
ZCPR3 shell and Jay Sage's column in The Computer
Journal on the same topic.
- Rick Charnes, 7/18/88
Most amusing how you keep turning a conversation about WS4 as a
shell into a conversation about shells in general. I am curious as
to why you insist on doing this. I rather chuckled in your using
the marvelous ZFILER as a defense of WS4 being a shell -- please
don't blaspheme such a wonderful program in this manner!
If you have read any of the documentation I have written for my
various aliases or my "Forever Z" column in the Morrow Owners
Review, you will know that I am a particular connoisseur of the
exotic shell and shell variable programs that many don't even use
regularly such as SHSET, SHVAR, GETVAR, RESOLVE, FOR (I even once
went for days with Dreas' SH20 as my main shell -- now that's
interesting!) and keep pushing for their increased use -- not to
mention standard ones such as ZFILER.
The ZCPR3 shells and shell variable utilities are wonderful. I
relish my use of SHVAR and RESOLVE and recently went on an alias
rampage using SH.VAR as a sort of "data file". I had SOME of the
same reaction that you did (saw your note on Lillipute) to Jay's TCJ
article. Jay has, from what I've been able to gather, simply not
gotten around to incorporating into his regular repertoire some of
the more esoteric shell variable utilities that many of us use and
love and would never do without.
But Jay certainly wasn't coming out "against" shells or the shell
variable utilities -- certainly the author of ZFILER couldn't be
fairly accused of that -- but merely the way the shell concept has
been implemented in some programs. He said nothing about the shell
variable utilities, which strictly speaking must be distinguished
from the shells. I admit that his discussion of the shell stack and
the shell concept without mentioning once any of the shell variable
utilities does by default help to perpetuate the community's
ignorance of these programs. But perhaps this is Dreas' (or my) job.
If we distinguish the "menu shells" -- the MENU --> ZMANG/VMENU -->
ZFILER continuum -- from the shell variable utilities, even though
both require the use of the shell stack I think it could safely be
said that for some reason still unknown to me, MOST in the Z
community people rarely use or even know much about the latter, and
this I join you in lamenting.
But do you disagree with, for instance, Jay's logic in arguing for
WS4 as a ZCPR2-style shell, which would allow its use as a "menu"
program AS WELL AS in an alias in a MCL sequence? And certainly Rob
Wood's implementation of W.COM is an improvement over the way it
previously was prohibited from being used in an alias. Steve Cohen
has also commented that he might have advantageously used the ZCPR2
concept in his ZPATCH as well, now similarly prevented from ARUNZ
use.
Maybe all this boils down to a disagreement between people for whom
ARUNZ and aliases are a fundamental feature of their Z-System use
vs. those who rarely use the alias facility of Z. For the latter --
of course! -- WS4 as a full ZCPR3 shell is a natural; there's
nothing lost and everything gained.
On the other hand, for me ARUNZ is the _fundament_ of ZCPR3; it is
its crystallized essence. It is the Z utility -- nay, the operating
environment -- which gives me more joy, creativity and opportunity
for learning and experimentation than any other. And naturally, as
you would expect, something that cannot be used in that environment
.. well, I don't like that.
If the disadvantages of being unable to use a ZCPR3 shell inside an
alias are NOT outweighed by the advantages of a program's being a
full Z3 shell, well --- that's the point at which I must question
what's going on. That's the balance that must be weighed. Whenever
we consider making a utility a ZCPR3 shell we must face squarely up
to the fact that in doing so we are going to be locking it out from
a major, very important feature of ZCPR3 -- the alias-creation
facility. And for a larger number of people than I think you might
suspect, those are people's feelings about the status of WS4.
I've always seen my own ZCPR3 practice and ideological underpinnings
as incorporating a synthesis of the Sage/ARUNZ school on one hand
and the Dreas Nielsen/shell variable school which I have defended in
my alias documentations against all detractors, or even more
insidiously those who simply ignore and never use the shell variable
programs. As far as I know the shell stack is absolutely essential
to these latter type of programs, and Jay erred in not giving these
programs -- and the shell stack they require -- their due. I love
RESOLVE and SHVAR and use FOR -- yes, from the command line, simply
because it's so much fun -- every occasion I get.
I have similarly used the SHSET/CMD duo for as long as I have been a
Z fan. In fact this is why I have configured my system for 4 shell
stack entries of *64* bytes each -- a 32-character command line is
far too limiting for any serious SHSET work. I have also recently
uploaded Dreas Nielsen's modification to the ZCPR33 CP -- that he
released specifically at my request -- to allow for flow control
within custom shells. I think Jay will disagree with what Dreas has
done, and prefers rather to EITHER implement flow control
system-wide but NOT while while custom shells, or with the SHELLIF
equate within custom shells but NOT system-wide. Discussion on this
topic should prove interesting.
But all this is neither here nor there. The point that we were
discussing in previous messages here is not the value of shells in
general, which needs no belaboring here, but rather specifically of
WS4 being implemented as a ZCPR3 shell. You have said not a word to
convince me of a single advantage in its being this way and I can
only take your silence to confirm me in my belief that it was a
mistake. I was rather amused by your comment, "Most of the
complaints I have seen about WS4 are really misuse of a shell." This
is funny! I suppose from a certain point of view trying to put WS4
into a multiple command line could be viewed as a "misuse of a
shell" --- but it begs (and implicitly skirts) the question of why
WS4 should be a ZCPR3 shell in the first place. As I said
previously I am quite convinced there are far more people, if -- as
with the current implementation of WS4 -- WE ARE FORCED TO CHOOSE
BETWEEN ONE OR THE OTHER, who would rather put WS4 into a multiple
command sequence than use it as a full Z3 shell.
Ok, I just spent 20 minutes or so using WS4 as a shell, utilizing
the shorthand feature to define various keys to run the "R" command,
then a (possibly multiple) command sequence, and finally a carriage
return. I defined key "z" as:
RECHO LOADING ZFILER...;ZFILER^M
This is nice, I agree. And I spent Saturday evening with Dave
McCord who showed it to me on his SB180 (or was it is DT42, I can't
remember) with the RAM disk, and it's even nicer.
But I just don't see that using it as this kind of menu shell has that
much usefulness. I simply don't see it as the kind of thing that
many people would _do_. I don't know. I'd like to hear your point
of view and others'. I'd like to hear that having this kind of
"interface to the operating system" is important for you to have
FROM WITHIN WS4. And most importantly --- IS IMPORTANT ENOUGH TO
GIVE UP THE ABILITY TO RUN WS4 FROM AN ALIAS. My suspicion is that
you don't use ARUNZ much, and I would bet a dime to a dollar that
anyone who defends the implementation of WS4 as a ZCPR3 shell also
doesn't use ARUNZ or aliases much. The more I think of it, I think
_this_ is really the crux of the issue, the meat of the whole
question.
Furthermore, using WS4 as an ersatz MENU.COM seems quite limited,
since it doesn't even have the ability to "hold" and act upon a
"pointer file" or system file and run its CL sequence on that a la
ZMANG/VMENU or MENU respectively. Lastly, one is not even returned
to the "shorthand" "menu display" but rather to the WS opening menu,
so an additional keystroke is required to get back to where you
started. Again, maybe on a RAM disk it feels different, but for me
the advantages just don't outweigh the disadvantages.
