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.

I look forward to your response.