The Computer Journal, Issue 50
Z-System Corner
© Jay Sage
Reproduced with permission of author and publisher.
The main subject for this column will be PCED, an operating system extension program for MS-DOS that gives one a working environment as close to Z-System as I have seen for MS-DOS. First, I have a few other small items to cover.
ZEX Script Correction
My ZEX script for formatting disks on the SB180 using the FVCD utility had a mistake, and I would like to publish a correction (due once again, I believe, to the legendary mistake-catcher and bug-fixer Howard Goldstein).
I, and many others, keep forgetting that the flow-control string tests performed by the IF commands (resident and transient) are not string tests at all; they are file name tests. Thus, if we have
IF EQ D:A.B B:A.B
the test will return TRUE, since the file name parts are identical. Directory prefixes are ignored.
In my ZEX script I wanted to detect a string of either "F" or "F:". The proper way to do this is with the command
IF EQ :$1 F
The colon before "$1" forces the "$1" string to be taken as a file name even if it contains a colon, since a directory prefix (the colon) has already appeared. Any additional colon in the "$1" string will be taken as a file name terminator, and it and anything after it will be ignored. Thus, if the command line token is "F:JUNK", the test will return TRUE.
Z-Node Update
It has been some time since we last published the Z-Node list, and there have been a couple of changes. We lost Z-Node #73 in Missouri. On the other hand, Z-Node #40 in Winnepeg, Manitoba, has been revived after years of neglect. The node has been transferred to new sysop Greg Kopp. We also have good news about accessing nodes 21 and 32 in South Plainfield, NJ. Both can now be reached by PC-Pursuit.
Finally, I would like to pass on a message I received by Internet email from Helmut Jungkunz, the incredibly energetic Z-System enthusiast in Munich, Germany. (He has produced German editions of the NZCOM and Z3PLUS manuals!) See the side panel for the text of his message.
PCED: Professional Command Line Editor
We now turn to the main subject for this issue. For many years, even after I had a Compaq 386/16 DOS computer at work, I continued to use CP/M machines. Among my collection were a couple of Ampros and a Wave Mate Bullet. The Z-System was so far superior to MS-DOS that the CP/M machine was often easier to use, even though its raw computing power was far less than that of the DOS machine. Several circumstances have led me at this point to retire the CP/M computers at work.
For one thing, I make heavy use of several applications that require a big machine. I do all my writing, including scientific and mathematical work, with TeX (actually LaTeX); I do a lot of my calculating with MathCAD, a computerized blackboard; and I now use PSPICE for electronic circuit simulations. All of these applications require about 500K of free memory. This is way beyond anything CP/M could dream of supporting; unfortunately, it sometimes exceeds what MS-DOS can provide! I have to be very careful about the drivers I use and how I load them, or I end up with too little free memory. The 386 is now tweaked up to the point where it just barely handles the jobs I need done.
The second thing is an operating system extension called PCED (for Professional Command Line Editor) that makes DOS bearable. It provides the closest thing to a Z-System interface that I have found for MS-DOS computers. I began to use version 1 of PCED many years ago. It was a great improvement over plain DOS, but there were many areas where the author just had not thought things through far enough. This, I find, is typical in the DOS world, where programmers do not share their work as we do in the CP/M community, and any given program tends to be limited to what one programmer can accomplish.
I contacted the author of PCED several times, and during one call he told me that he was working on release 2. At that point, I began to lobby heavily for certain improvements. Most importantly, I sent him copies of old TCJ columns that described ARUNZ and LSH. PCED had alias processing, but the parameter parsing was as feeble as that provided for BAT files. Only complete tokens could be passed; there was no way to extract pieces of tokens, such as just the path or just the file name or extension. There was a command history facility, but it, too, was extremely primitive. To find an old command line, one had to back up line-by-line until the right command was found; the computer did not provide the help with searching the way EASE and LSH do.
Well, PCED release 2 is now out. The author has not copied the user interface of ARUNZ and LSH, but he has incorporated most of the functionality. In addition, with the far greater memory available on a DOS computer, PCED is able to do some things that we cannot with our 64K machines.
I'm sure I am not the only Z-System user who also has occasion to work on DOS machines, so I would like to use this column to describe some of the main features of PCED. Perhaps we can even learn something that we can apply in the Z-System. I will start with the features that are most like those we are familiar with from the Z-System and then go on to some of the extra capabilities of PCED.
As usual when I see a program that should be of great interest to Z-System enthusiasts, I try to get it added to the Sage Microsystems East product line. PCED is no exception, and SME now offers it for the very attractive price of only $50.
Multiple Commands on a Line
With PCED running you can enter multiple command lines at the DOS prompt just as you are used to doing with Z-System. You can set the command separator to the character of your choice. The default is the caret character, which I find to be a nuisance to type, since it requires pressing the shift key. Besides, for Z-System compatibility I prefer the semicolon. Occasionally this causes a problem, however, because some DOS commands use a semicolon in their syntax (the PATH command, for example).
There are several ways around this problem. There is a simple command to turn off PCED entirely so that user input goes straight to DOS. Then one can enter such commands with no interference. One can also change the separator character on the fly. Thus a single command line can change it to the caret, run the command that requires a semicolon in its argument line, and then switch it back to semicolon. Such a command line might look like this:
ced chainch ^;path dir1;dir2;dir3^ced
chainch ;^echo back to semicolon;echo all done
The first command, separated by a semicolon, is
ced chainch ^
CED.EXE is the executable program that constitutes PCED. It's 'chainch' option redefines what PCED calls its chain character (what we know as the command separator). PCED then parses off the next command using the new separator:
path dir1;dir2;dir3
PCED is able to do this because it buffers user command line strings and feeds the individual commands one at a time to DOS's COMMAND.COM. Since, unlike MS-DOS, the Z-System supports multiple commands on a line at the operating system level, ARUNZ ships the entire alias command line to the command line buffer immediately.
Alias Scripts
PCED supports alias scripts, which it calls 'synonyms', and it has much of the alias processing power of ARUNZ. As a result of our efforts, the author has incorporated a very powerful parameter parsing facility. It can pull apart tokens into the drive, path, filename, and filetype, and it can return the current date and time and the default drive and path. It lacks only the parameters for accessing memory and the system environment (things like the number of drives defined). PCED command lines can recognize DOS environment variables created using the SET command. As under the Z-System, aliases can be nested to any degree. The only limit is the total length of the multiple command line buffer. The default length is 512 bytes, but you can make it longer if you like.
Here is a command that defines a synonym that displays a directory listing with the file specification automatically wildcarded:
ced syn d "cdir %1{$r*.$e*} &r"The 'syn' option on the CED command causes it to enter a new synonym (alias) definition into memory. In this case, the name of the alias is 'D' and its prototype command line is the text enclosed by delimiter characters (here the double quote, but any character may be used).
The script in this example invokes the CDIR command, which lists the files in a directory. We will have more to say about CDIR later, but any directory listing program could be used (even DOS's horrible DIR). What is interesting here is how parameters are parsed.
As with MS-DOS batch files, command line tokens are designated by the percent sign followed by a number. What is different here is that curly braces can be used to indicate that further processing is to be performed. The dollar sign introduces special symbols. The first one, '$r' represents everything in the token except for the file type and the dot separator. The form '$e' represents the extension. Other characters are literals to be included exactly as entered into the script.
There are parameters of a different type that are introduced by an ampersand. In this example '&r' represents the rest of the tokens on the command line after any that have been referred to explicitly (%1 in this example). Thus, if the user enters the command
d d:\main\sub\a.b /date
PCED will generate the DOS command
cdir d:\main\sub\a*.b* /date
A question mark can be used to define a default value for the parameter in case the user enters no token. Here is an example:
ced syn format "format %1{?a:}"Now when the user enters just "format", DOS will get the command
format a:
but if the user enters "format b:", that is what PCED will send to DOS.
If you have been really alert, you may have wondered how we could get away with defining an alias command named FORMAT in terms of a real command called FORMAT. Well, PCED is pretty sophisticated in the way it handles this and prevents infinite recursion.
First, it is important to note that PCED always treats commands as aliases first. This contrasts with the way ARUNZ operates under Z-System, where ARUNZ is invoked only if the command processor cannot handle the command. PCED's behavior arises out of necessity. In Z-System, ARUNZ is a tool invoked knowingly by the operating system; PCED, on the other hand, has to sneak in front of the highly incompetent MS-DOS operating system.
Second, PCED provides several ways to turn off special processing of a particular command. The command
ced ignore cmdname
will cause CED to completely ignore any command line that starts with the specified command. There will be no parameter expansion and no stacking in the history. This is the most extreme way to turn off special processing.
A slightly less drastic measure is to put a special character in front of the command that tells PCED to ignore the command this time only. The default for this character is the asterisk, but for compatibility with Z-System I redefine it to be the period using the command
ced ignorech .
Then when I enter a command like
.path subdir1;subdir2;subdir3
This, obviously, is another way to permit the command separator in the command line.
Finally, a command can be entered with a leading space, since synonyms are matched only if they begin with the first character. For example, if I have defined an alias with the name DIR but want to run the standard DOS DIR command, I can enter either of the following commands:
.dir
<space>dir
The latter has the advantage that the command line will still be processed by PCED and placed on the history stack. This is especially useful for an alias definition like the following:
ced syn dir "echo running dir; dir %1"
Without the leading space before the DIR in the script, this would be a circular definition, and any invocation of DIR would result in a command stack overflow in PCED. The space option must be used here if we want the parameter expansion to be performed. If the first command in a definition is the same as the synonym name, then synonym processing is automatically suspended for that command; that's why our FORMAT alias above was OK.
Well, I think this is enough detail to give you the idea of the sophistication that is possible with PCED aliases. One thing I would like to make clear at this point is that we do not have to enter all PCED commands (such as synonym definitions) manually each time we start the computer, as the examples above may have suggested. This would clearly be an enormous inconvenience. PCED includes a 'load' option that will read a file containing any valid PCED commands, that is, arguments that would normally follow a CED command. For example, I have a file called PCED.CFG that I invoke as part of my AUTOEXEC.BAT file using the following form:
ced load c:\pced\pced.cfg
The PCED.CFG file contains lines like the following:
chainch ;
ignorech .
syn d "cdir %1{$r*.$e*} &r"
... (other synonym definitions)
History Shell
PCED provides a command history shell environment like that of LSH. Command lines can be edited nicely as they are entered, just as with LSH. The history function in PCED is called the command stack. Commands can be viewed either in line mode or, by loading the optional VSTACK program, in full-screen mode. If a partial command line is entered, the search function returns only those lines that begin with that string. Even the full-screen display shows only matching lines. Unlike LSH, however, one cannot edit the full command history but only individual command lines.
Another advantage LSH still has over PCED is in the options it offers as to how the next-command pointer is positioned after a command has been executed from the history. In PCED, the pointer always points between the command just executed and the one that followed it in the past. This is similar to LSH's auto line sequencing mode, except that LSH is actually ready to execute the next command line with just a carriage return. With PCED one must press the down arrow key.
I have found that PCED's method easily results in confusion as to which direction one should search for a new command. I have LSH configured to use line auto line sequencing only in full-screen mode but to put the pointer at the bottom of the history when in line mode. In general, I think that the author of PCED could have learned a lot had he been able to see LSH in operation.
Command Completion
PCED has a command completion feature similar to the one in LSH, but slightly more powerful even. As with LSH, if you begin to enter a command line, such as
edit tc
and then press the TAB key, PCED will try to complete the last token on the line, "tc", by looking up all files in the specified (or current) directory and displaying the next one each time the TAB key is pressed. Thus if the directory included TCJ49.WS and TCJ50.WS, the command line would cycle through the following as the TAB key is pressed:
edit tcj49.ws
edit tcj50.ws
edit tc
PCED also allows one to enter a wildcard file specification and then have the TAB key display the matching files in sequence. Thus one might enter the command line
edit *.ws
I thought this was something that LSH did not offer, but I just tried it and discovered, to my surprise, that LSH does this too!
The area where PCED is a little more advanced is with completion of the first token on a line. PCED is smart enough to scan only executable files and to omit the file type. It also automatically supplies a trailing space so that one is immediately ready to enter any command arguments. The closest thing to this with LSH would be to enter a command line of
e*.com
and then press TAB until "edit.com" appeared. Then one would backspace over the ".com" and enter the command tail. PCED does this automatically when just "e" is entered on the command line. PCED will also include in the scan PCED synonym command names. This is a nice feature, but I don't make much use of it, perhaps because I am not accustomed to it from Z-System.
Flow Control
PCED provides a very rudimentary flow control, vastly inferior to what we have in Z-System, but better than nothing. A CED option called CANCEL will discard any pending commands and insert the command (which may be an alias) given in its argument. It can be used with the standard DOS IF command, as in this example:
ced syn test "if ex %1{$r.bak} ced cancel
dobak %1;nobak %1"If a BAK file already exists, the DOBAK command or alias will run; otherwise the NOBAK command or alias will run. This is essentially a single level of flow control with no ENDIF. It reminds me of the so-called recursive alias that I invented before Dreas Nielsen showed how to do recursion rigorously under Z-System (see TCJ issues 27 and 28). If TEST is called from another alias with multiple commands, all pending commands from that script will be lost if the CANCEL branch is taken. This makes nesting impossible and can cause some unplanned, unexpected, and undesirable behavior.
With a little bit of work, I think that the author of PCED could have implemented a full flow facility like the one in Z-System. Having had no experience with it, he probably could not appreciate just how much power it provides. Perhaps I will be able to convince him to put it into version 3 of PCED.
Unique Features of PCED
While PCED does not have all the power of Z-System in the areas described above, it does have many features that we do not have, and probably could not have given our memory constraints.
PCED operates entirely from memory, with fixed-length buffers allocated for its various features. As a result, PCED performs its functions with lightning speed. Having its alias definitions and other information in memory also allows it to do some interesting and useful things, some of which we will describe below.
Dynamic Alias Definitions
As we have already seen, PCED allows new alias definitions to be added directly from the command line at any time. This can be handy in its own right, but what is really spectacular is that one alias can create or remove other alias definitions! For example, one can create an ADDPATH alias that not only adds a new directory element to the search path but also creates an alias RPATH (restore path) for resetting the path to its previous configuration. RPATH includes a command (the PCED "clear syn" option) to remove its own definition after it has performed its function!
There can be multiple definitions for the same alias, with the newest one always being used. Thus, running ADDPATH several times will add several new path elements and create several new RPATH aliases. Each time RPATH is run, it sets the path back one step and then removes itself. Thus, the PCED aliases create, in effect, a path stack.
Many other creative uses like this can be implemented. For example, I have some scripts like the following:
ced syn wow "makewow &a;xwow;ced clear syn xwow"
When this alias is invoked, the alias XWOW has not even been defined! The program MAKEWOW creates it based on the parameters passed in the command tail. Then the XWOW alias is run, and finally its definition is removed. I use this complex approach when the program MAKEWOW, which figures out what needs to be done, uses too much memory for it to perform all the tasks itself. The alias that it creates runs later, after MAKEWOW is no longer in memory.
PCALL (Parameter Recall)
With PCED one can declare a list of commands for which automatic parameter recall should be performed. For these commands, the last command line involving the command is stored in a special buffer. The next time the command is invoked without any command tail, the previous command tail is provided automatically.
I have EDIT assigned to PCALL status using the command
ced pcall edit
When I first started writing this column, I would have used the command
edit tcj50.ws
Later, I would type "edit" alone on the command line, and the original command would be executed for me. This is a very handy feature but probably not important enough to implement in Z-System, since it would require additional disk activity to save and recall the information. With LSH I would type "ed" and then control-O to recall the last editing command.
[I thought new code would be required to do this under Z-System, but Howard Goldstein showed me that it can be done already! He suggested the following ARUNZ script, assuming that WS is one's editor:
EDIT if ~null $1;shvar edtail $*;fi;resolve ws %edtail
This uses the shell variable facility of Z-System. Storing and then recalling the variable "edtail" would take some time unless the programs and data files are on a RAM disk.]
User Synonyms
So far we have described how PCED functions at the DOS prompt. PCED is also capable of functioning when application programs are prompting for user input. This only works when the input is requested using a particular DOS function call, the one equivalent to CP/M's buffered line-input function (#10). This feature of PCED is normally not engaged (since it could cause problems) and must be activated by entering the command
ced on user
Once it is activated, many PCED functions become active. The full command line editor can be used, except that command completion using the TAB key is disabled. There is a command history stack that is separate from the one that saves DOS commands. PCED commands can be executed, including those that define, edit, or remove synonym definitions.
Most importantly, one can now define what PCED calls "user synonyms". For example, you might create a display alias for use in DEBUG with the following command:
ced usyn d 'D DS:100 L100'
User synonyms - defined with the 'usyn' option - and command synonyms - defined with the 'syn' option - are completely independent.
Few of the programs I use regularly get their input via MS-DOS's buffered console input function, and, therefore, I never use this PCED facility. Under the right circumstances, however, I'm sure it could be very handy, and perhaps I should give it a try some day.
Internal (Directory) Synonyms
There is a third class of synonyms that I have found very helpful (and wish I had on my Apollo minicomputer running Apollo Domain or Unix). With its nice, flat named directory structure, the Z-System does not have the problem, but on systems with tree-structured directories, one wastes enormous amounts of time trying to type excruciatingly long directory specifications. For example:
cd d:\editors\wordperf\letters\personal\john
Tree-structured directories make for a very logical and orderly collection of files, but they sure aggravate finger-tip calluses!
With PCED we could define an "internal" synonym as follows:
ced isyn john "d:\editors\wordperf\letters\personal\john"
Then we could change default directories by entering the simple command
cd @john
or edit a file there using the command
edit @john\file.doc
The '@' sign is a signal that the string following it is to be interpreted as an internal synonym name and expanded. I use this mainly for expanding directory names, but it can be used to provide shorthand string definitions for any purpose one wishes.
You do have to watch out for some confusing side effects. Suppose you wanted to edit a file with the name "@johnson.doc" and enter the command
edit @johnson.doc
The "@john" part would be recognized as an internal synonym, and the command would turn into
edit d:\editors\wordperf\letters\personal\johnson.doc
One has to watch out for all of PCED's special characters. They can generally be made to be taken literally by prefixing them with the variable prefix character (normally '&'). Thus one would enter
edit &@johnson.doc
There is, unfortunately, a bug in PCED that prevents this from working in alias definitions. I have pointed this out to the author and hope he will have a maintenance fix. It causes me great difficulty with some aliases for sending Internet electronic mail (where all addresses contain the '@' character).
User Programs
PCED has a very powerful facility for adding independent resident programs. It never occurred to me before, but this is somewhat like the RCP (Resident Command Package) in the Z-System. PCED comes with a number of very nice programs of this type, and software developers can write new ones.
These programs have several advantages. If PCED's user mode has been turned on as we described earlier, then they can be activated while inside an application program. Some of the programs - such as VSTACK, the full-screen history shell - are designed to augment existing PCED features. Other programs are just particularly nicely conceived and written. I will describe only a few of them here.
CDIR is a directory display program whose format I particularly like. It has many options that can be declared on the command line (or automatically in aliases). It can list files in anywhere from one to four columns; it can sort by filename, filetype, or date and in ascending or descending order; it can include only directories, only files, or both; it can display different types of files in different colors for easy identification. It can also generate a file containing the list of file names for processing by other programs.
HS (for "HindSight") buffers screen output and allows one to retrieve it. Now when stuff scrolls off the top of the screen before you could read it, you can get it back! This is particularly usefull on very fast computers, where information can disappear before the finger can respond with a control-S. One can also write the captured screen data to a disk file. In PCED2, HS can be configured to use expanded memory for its buffer, so one can have a large buffer without losing valuable program memory space.
KEYDEF allows macros to be assigned to function keys. Separate definitions apply at the DOS prompt and at user input prompts inside application programs.
KEYIN establishes a buffer which holds simulated keyboard input. When the next prompt for user input occurs, KEYIN will supply characters from its buffer. This allows programs that operate only in interactive mode to be run in batch mode. KEYIN is particularly useful in alias scripts and BAT files.
SEND is a program to send character strings to any device or file. It is similar to the DOS ECHO command but is more flexible. For example, while ECHO always sends a carriage return and linefeed at the end of a line, SEND sends only what you tell it to. This can be very important, such as when sending setup commands to a printer or when constructing a prompt line in pieces.
PCED and Personal REXX
PCED has special interfaces to allow it to work with certain other software packages. I particularly appreciate its coupling to Mansfield Software's implementation of the mainframe batch processing language called REXX.
REXX would be worthy of an entire TCJ column, so I will not say much about it here. Basically, it is a programming language for processing strings and generating command lines. Strings can be pulled apart into their words and characters; strings can be concatenated with other strings; strings can be substituted for other strings. All kinds of program looping can be performed. There is a complete interface to the operating system so that one can get the system time and date, check for the existence of files; read and write file contents; change file attributes; and so on. The resulting strings that REXX builds can then be passed as commands to the operating system's command processor.
REXX programs are written in files with the extension REX. Normally one would have to invoke them using the explicit command
rexx filename
where "filename" is the full path specification of the REX program file. With the PCED add-on program RXRUN loaded, these REX files can be executed automatically, just as BAT files are. In this way, REXX becomes an integral part of the system.
When I described the WOW alias earlier, what I really had in mind was REXX. It takes up over 200K of memory, so one often cannot afford to have it resident when commands are run. To get around this problem, instead of having REXX pass the ultimate command lines to the operating system, I have it pass CED commands that define a new alias. That alias is then run after REXX is finished and no longer resident in memory. Without PCED, REXX would lose much of its power for me.
Well, that completes what I will say this time about PCED. I hope that many of you who use DOS computers will order PCED so that the author will feel it is worth his while to add more of the features that we Z-System users would like to see.
[This article was originally published in issue 50 of The Computer Journal, P.O. Box 12, South Plainfield, NJ 07080-0012 and is reproduced with the permission of the author and the publisher. Further reproduction for non-commercial purposes is authorized. This copyright notice must be retained. (c) Copyright 1991 Socrates Press and respective authors]