CP/M/CPM_CDROM.iso/jsage/znode3/info/histshel.not

Text File | 1994-09-02 | 7.9 KB | 185 lines

This is an extract of a wish list I sent Rob Friefeld a few weeks
ago.  Rob is working on a new ZCPR3 history shell that will be
full-screen, so one will (optionally) be able to not only recall
but actually see at a glance the last, say, 23 or so commands
issued and then move to the cursor to the one desired for
execution.  When I heard he was working on such a program I was
reminded of a feature I had long wanted to see in a command
shell.  I wrote him a note detailing my wish, thinking however
that it was too far out and sophisticated to be done on our 8-bit
machines.  He responded, unbelievably, that he feels it could be
done in about 100-150 bytes.  He was, however, concerned about
code size and was interested to know how valuable such a feature
would be for others, and requested I make this note public for
the purpose of soliciting comment from other history-shell users.
I herewith do so.  Please note that I believe the implementation
of such a feature would be an extraordinary advance for ZCPR3.
Your comments are very strongly solicited; I will forward them to
Rob.

                                         - Rick Charnes
                                         January 1, 1989

[...]

(3) This is the trickiest.  I'm sure you're going to say it's
impossible.  But I'm hoping you're like a Marine for whom "the
difficult we do immediately, the impossible takes a little
longer."

In my use of ZCPR3 I have settled into a regular and consistent
pattern of issuing multiple commands, separated by a semicolon,
from the command line.  It is silly to limit the use of our
wonderful MCL buffer to aliases and the like; it is fairly easy
for me to anticipate my next 1 or 2 or 3 moves.  Just now I was
about to issue a multiple command and I was frustrated at my
inability to do something that has bothered me for quite a while
and I thought that this time I'd at least describe it to someone.
I'm sure it's a fairly regular and common thing, but I've never
heard anyone bring it up for public discussion.

All I was doing was renaming a file, then loading it up for
editing with VDE:

RENAME DAY.CMD TODAY.CMD;VDE TODAY.CMD

OK.  ** I'M TIRED OF HAVING TO TYPE THAT SECOND 'TODAY.CMD'.  ***

There are of course a number of ways one can deal with this and
keep the string of characters 'TODAY.CMD' somewhere in memory or a
disk file or on the shell stack, so that you don't need to retype
it.  You can make an alias (I actually wrote and released one
probably two years ago, called RCOM, short for Repeat COMmand).
You can use, as I often do, Dreas Nielsen's FOR.COM and
PERFORM.COM, that I guess respectively store it on and then
access it from the shell stack:

         FOR TODAY.CMD;PERFORM RENAME DAY.CMD $X$|VDE $X

(The '$X' 'holds' the name of the 'FOR'-ed string and the '$|' is
PERFORM.COM's substitute command separator)

Etc., etc.  But the worst problem with the above approaches is
not even that they involve an extra step and command and some
consequent and inevitable slowness due to extra disk access
(which I wouldn't mind that much and would accept as the price to
pay for the feature), but that THEY REQUIRE YOU TO KNOW BEFORE
YOU START TYPING YOUR FIRST COMMAND THAT YOU *ARE* GOING TO LATER
DO SOME SORT OF ITERATION.

Generally I don't.  It just hit me AFTER I'd typed

                    RENAME DAY.CMD TODAY.CMD

that I was next going to enter:

                          VDE TODAY.CMD

If I'd decided *beforehand* I could have used FOR and PERFORM,
though these programs of Dreas' that access the named shell
variables are sometimes noted for their slowness.  Or with my
RCOM alias which takes as its first parameter the file that is
going to be repeated and the second as a token to one of the
command verbs I could have done:

RCOM TODAY.CMD DAY.CMD RENAME VDE

But the point is that THIS ALL ACTS AS A DRAG TO ONE'S
SPONTANEITY IN USING THE COMPUTER.

So, I was thinking: how could a command editor/history shell play
a role in this?  We have been quite adept at packing these
programs with a good number of nifty features.  Any chance this
kind of thing could be added?  Some scheme whereby the program
AUTOMATICALLY, AS THE USER IS TYPING, "records" the keystrokes
(I guess it would have to be to memory, rather than a disk file)
and allows him to access these very same keystrokes later IN THE
SAME COMMAND LINE?

If it would have to take up TPA -- and I imagine it would since
we cannot have yet opened up a file since we haven't yet hit <CR>
-- I for one would be willing to sacrifice a k or two for this
feature.

I am reminded of a program that was floating about a year or two
ago called ZX.  It was written by a fellow named Mike Yarus of
Boulder, Colorado in January 1986.  It's not a ZCPR program (the
Z' stands for horiZontal sort because that's how it does its
directory function, but rather an all-purpose CP/M
directory/copy/erase/rename utility.  It's one of those many
actors that have come and go on the great CP/M utility stage.
It had a really nifty feature, though, that I've never seen
duplicated anywhere since: "filename memory," in which recently
used filenames can be re-entered with a single keystroke during
later operations.  A '1' represents the first parameter of the
previous operation, a '2' the second.  So if the user first
entered:

ZX JOE.LTR JOSEPH.LTR R   ; the 'r' parameter is for R)ename

then

ZX 2 SECOND.FIL C         ; the 'c' is for C)opy

would then rename JOSEPH.LTR to SECOND.FIL

I never really used it much -- never did like the horiZontal
sort -- but I always liked the "filename memory" idea.  In the
documentation Mike mentions "The stored filenames are kept in a
seldom-used place.  But they are in memory, of course..."

Of course what I'm suggesting for the command editor/history
shell would be different and probably harder to do, since I'm
talking about writing stuff to memory even before the user hits
the carriage return and the command processor is invoked.  But
ideally I would like, in my example above which started me on
this whole thing, to be able to enter something like:

RENAME DAY.CMD TODAY.CMD;VDE 3

where the 3 would represent the 3rd token on the command line, so
it would translate into 'VDE TODAY.CMD'.  Or $3, or something
like that, if we were worried about files named '3'.  Nice would
be defining tokens as anything separated by EITHER a semicolon OR
a space, so that:

VDE LOVE.LTR;RENAME PROG.ASM PROG.Z80;VDE 5

would call up VDE to edit PROG.Z80.

Or, of course:

VDE LOVE.LTR;RENAME PROG.ASM PROG.Z80;1 5

would do the same thing.

This is all off the top of my head and I have no idea if this
kind of instant 'character recording' and playback is possible on
our humble machines.  2k TPA?  3k TPA?  50k?  Shell stack?  I
don't know.

Dreas Nielsen works always within the SH.COM shell (he never
bothered with the low-grade history shells such as HSH and EASE),
wherein if LOVE.LTR is already and previously assigned (inside
SH.VAR) to the shell variable 'L', for instance, then:

RENAME LIKE.LTR %L;VDE %L

entered at the command line already works turns into:

RENAME LIKE.LTR LOVE.LTR;VDE LOVE.LTR

As I point out in my upcoming TCJ article, running inside SH.COM
is like having RESOLVE.COM permanently running without it being
there at all.  But this of course requires forethought and
planning: LOVE.LTR must have already been previously stored as a
shell variable to the SH.VAR file.  My idea is to have the
recording done as the user types...

Well, I've just been doing a lot of work with named shell
variables and they're on my mind.  They're probably not
appropriate to this job at all; the concept and syntax just got
me thinking.

Semper fidelis.