TCJ #50 R60 The Z-System Corner PCED, the Z-System for MS-DOS Computers Jay Sage 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 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.