CP/M/CPM_CDROM.iso/jsage/znode3/tcj/tcj36.ws

Text File | 1994-09-02 | 34.9 KB | 616 lines

     I wonder if the approach of a TCJ deadline will ever find me with noì
pressing commitments to interfere with my writing this column.  That isì
always my dream, but the prospects of its happening get dimmer by the month. ì
My schedule just keeps getting worse and worse.  This time I was not evenì
able to start the column until after the deadline had passed.  As a result,ì
it will surely be shorter than usual, and it will probably not haveì
benefited from my usual multiple rewrites and the careful scrutiny of Howardì
Goldstein, on whom I have relied in the past not only to check my code butì
to check my writing as well.  He is remarkably good at both jobs!

     As has become the pattern for my columns, before I turn to the mainì
technical subject, which will be a discussion of some of the capabilities ofì
the ZFILER shell, I would like, to talk about a few nontechnical issues.


                            Z Systems Associates


     It may have taken the retirement of Frank Gaude' and the demise ofì
Echelon (at least as a force in the Z community) to make me realize just howì
much work Frank must have been doing, and I can now understand why he was soì
burned out in the end.  The reason why I now appreciate his efforts in a wayì
that was impossible before is that I have been in the process these last fewì
months of setting up a new company -- Z Systems Associates or ZSA -- toì
serve as a central marketing organization for Z-System and related products.

     Frank's retirement probably could not have come at a worse time for us. ì
With NZ-COM and Z3PLUS we finally had Z-Systems that did not require aì
programmer's mentality and programmer's abilities to be able to set up andì
use.  We were also no longer limited to CP/M-2.2 computers.  Our potentialì
market had now become the literally millions of people with CP/M computersì
of any kind, including especially the Commodore 128s and Amstrads runningì
CP/M-Plus and the CP/M-2.2 ADAMs.  We have never had any contact with thoseì
communities in the past, and it is going to take a lot of work to developì
those contacts now.

     The community of CP/M-2.2 hobbyists will, of course, be our marketingì
front line.  To that end, we have established two plans, one involving theì
Z-Node remote access computer systems and the other, the hundreds ofì
computer clubs around the world.

The Z-Node Plan

     Echelon had a nice plan that recognized the important role Z-Nodeì
sysops play in disseminating information about the Z-System and in providingì
support to those who use it.  It allowed Z-Nodes to act as dealers forì
Echelon's products and thus to gain some compensation for their efforts.  Zì
Systems Associates has started a similar plan.  I will not go into theì
details here, but if you are a Z-Node sysop and have not heard from me,ì
please drop me a line at the address in the Sage Microsystems East ad.

     Unfortunately, we do not have a list of the names and addresses of theì
Z-Node sysops.  Somewhere along the way that information got lost and wasì
never passed on from Echelon.  So, a couple of weeks ago I sat down at myì
computer on a Saturday afternoon and started to call all the Z-Nodes in theì
United States and Canada.  I did not count how many numbers were listed inì
Echelon's last ZNODES.LST file, but there must have been well over 50.  Atì
first I tried to figure out which ones were accessible by PC-Pursuit, butì
the task was monumental enough without having to put up with the perpetuallyì
busy PCP circuits.  My phone bill came a few days ago, and it was amazing toì
see the number of pages of calls.  Since each call was rather short,ì
however, the bill was surprisingly low.

     Although I started making the calls in the afternoon, I kept at it wellì
into the night.  At a point when I could hardly keep my eyes open, Iì
connected to a system out West and, as a new user, went through theì
procedure of identifying the city and state from which I was calling.  Theì
system then greeted me very nicely and reported that the time was 1:05 am. ì
Amazing, I thought!  That was just what my watch showed here in Boston. ì
This was the first system I had ever called that was so sophisticated thatì
it actually adjusted the time display to the caller's time zone.  Well, itì
wasn't until the next morning that I realized that the battery in my wristì
watch was failing and that the watch had jumped back three hours.  It hadì
really been 4 am!  No wonder I felt so tired.

     The whole experience of calling the Z-Nodes was rather disheartening. ì
I discovered that many Z-Nodes had long ago gone off the air.  The numbersì
of the more recently departed were answered with messages from the phoneì
company reporting that they were no longer in service.  Those long gone wereì
answered by actual people, who usually had had that number for over a year. ì
Considering that when my watch said 11 pm, it may actually have been as lateì
as 2 am, it is amazing how civil all of these people were to me.  Yes, theyì
admitted, they did get an awful lot of calls with no one on the other end. ì
I explained why this was happening, that they were being called by aì
computer, and I promised to try to get their numbers removed from the lists.

     Several Z-Nodes had become private systems, and I was prompted for aì
password without any signon message at all or just a brief, "private system,ì
enter password."  A few systems, as one would expect, had gone over to MS-DOS.  All in all, no more than half the nodes on the list appear still to beì
active.

     In view of this situation, I would like to encourage the establishmentì
of new nodes.  Some of the nodes on Echelon's list, I learned, actuallyì
never went into operation because the sysop was unable to get Z-Systemì
running on his computer.  With NZ-COM and Z3PLUS this will be much less of aì
problem.  If you think you might be interested in setting up a Z-Node orì
converting your present system to one, please give me a call or drop me aì
note in the mail.

The Z-Plan for Computer Clubs

     Computer clubs are probably the single most effective and valuableì
source of support to computer users.  To promote membership in clubs and atì
the same time to encourage more people to take advantage of the new Z-Systemì
software, we have established a plan whereby clubs can purchase the programsì
at a discount.  It is their option how that discount is distributed.  It canì
be passed on entirely to the club members, or the club can keep at leastì
part of it to support its activities.

     The Z-Plan project was initiated by Tony Parker, who serves as aì
marketing representative for ZSA.  He uploaded a file to many bulletinì
boards describing the plan, and you may be able to find it on a system nearì
you.  ZSA had not yet been formed at that time, and the file instructs clubsì
to send the necessary registration forms to Alpha Systems.  Alpha Systemsì
has agreed that ZSA should take over responsibility for the administrationì
of this plan.

     A revised version of the Z-Plan file should be on systems by the timeì
you read this column, but if you already sent information to Alpha instead,ì
it would be a good idea to send another copy to ZSA (again, see the Sageì
Microsystems ad for the address).  More importantly, if you belong to a clubì
that has not registered, have them write to me requesting a description ofì
the plan and registration forms.


                          My New Amstrad Computer


     One of the computers on which Z-System now runs and one which exists inì
very large numbers, especially in Europe, is the Amstrad.   This CP/M-Plusì
machine -- once sold in the US by Sears, Roebuck -- uses a very unusual 3"ì
diskette (unique might be a better word for it).  We were afraid that weì
would not be able to produce Z3PLUS diskettes for this machine, so I boughtì
one second hand (just what I needed, another computer!).  Since it appearedì
that we really had to have the machine, I probably paid a good bit more thanì
it would otherwise be worth, but I must say that it has been a very pleasantì
surprise.  (On the other hand, paying close to $400 for a hundred diskettesì
was a most unpleasant surprise.)

     I expected the Amstrad to be little more than a toy.  Instead, I haveì
found it to be a very capable machine and an excellent platform on which toì
run Z-System.  The main reason for this is its very nice RAM disk.  Myì
PCW8512 (it started life as a PCW8256, but it was upgraded) has a total ofì
512K of RAM, about 350K of which is available as a RAM drive.  With ARUNZ,ì
EASE, ZFILER, all their support files, and a few other critical files on theì
RAM drive, the Z-System really zips along.

     The native (non-CP/M) mode has also proved to be quite useful.  Theì
Amstrad was largely promoted as a stand-alone wordprocessor, and itsì
Locascript wordprocessing software is actually rather nice.  Like Macintoshì
software, it is very easy to use, and my 12-year-old son has really taken toì
it in a way he never did to my super-sophisticated PMATE editor.  Theì
keyboard is set up specially for the software, and the computer includes anì
integral printer.

     That printer is, in fact, rather interesting in its own right.  To keepì
the cost down, Amstrad buys just a raw printer mechanism, and they supplyì
the software drivers to emulate an Epson FX80 in the host machine.  Theì
printer is pitifully slow, but I actually use it myself now for quickì
letters because the Amstrad is so much faster to set up than my fancyì
systems.  The printer even loads single sheets of paper automatically, andì
that's more than my (at one time) $3000 Diablo HyType-II printer can do.  Ifì
you have an Amstrad computer or know of someone who does, I would be happyì
to help them get started on Z-System.


                          Special Acknowledgments


     Before we go on to ZFILER.  I would like to acknowledge publicly someì
very special recent contributions to the development of Z-System.

     David Johnson of Sunnyvale, CA, took my ZCPR34 source code and mustì
have gone over it not only with a fine-toothed comb but with an electronì
microscope.  In programming, I always give top priority to writing code thatì
has good features and runs reliably.  Code compactness is secondary.  Thus,ì
I am never surprised when I learn that one of my routines can be improvedì
slightly.  Nevertheless, I would never have believed that the Z34 code couldì
reduced by close to a hundred bytes, but David Johnson did just that!  Evenì
Joe Wright, who is deservedly acclaimed for his coding skill, had only takenì
out 10 or 20 bytes, and he was especially impressed by David's achievements. ì
With all the new space available, I can now start to think about more newì
features!

     The second person whose contribution I want to acknowledge is Billì
Tishey of Severn, MD.  Bill has proven something I have been trying to getì
across for a long time: that you do not have to be a programmer toì
contribute in a significant way to Z-System.  Bill has sytematicallyì
compiled the documentation for the complete collection of Z-System programsì
in a set of help files that runs (uncompressed) to more than a megabyte!  Heì
has grouped the help files into libraries with names of the form
Z3HELP-n.LBR, where 'n' is the first letter of the command name.
Z3HELP-A.LBR, for example, contains 21 files covering ARUNZ, AFIND, ALIAS,ì
and many other commands.  To my mind, this contribution is at least asì
valuable as those of program authors because it makes the programsì
accessible to the user.

  The complete set of files is posted on my Z-Node #3 and will graduallyì
make its way around the world (slowly probably, because of their size).  Inì
view of the exceptional value of Bill Tishey's help system, Sageì
Microsystems East will make it available on diskette for only $10 (SME'sì
usual copying charge is $15 to $20 per diskette).  Here are the rules.  Youì
have to send (1) preformatted diskettes clearly marked with the exact formatì
and sufficient to hold 800K of files; (2) a disk mailer for returning theì
diskettes (unless the one you sent the disks in is reusable); (3) returnì
postage; and (4) a return address sticker.  We can accept 8" SSSD IBMì
standard format (including 'flippy' diskettes) and most 5" soft-sectoredì
formats (anything on the menus of Uniform or Media Master on either theì
SB180 or an IBM AT).  Bill, himself, has an Apple and (I just spoke withì
him) is willing to make the same offer for diskettes in that format.  Hisì
address is 8335 Dubbs Drive, Severn, MD 21144.


                     ZFILER, The Point-and-Shoot Shell

     Now let's turn to the technical subject for this issue, the ZFILERì
shell.  Having written about shells so much in the past few columns, I amì
tempted to jump right into the thick of the subject.  However, judging fromì
the number of new subscriptions that SME alone takes each month, TCJ mustì
have lots of new readers with each issue.  Therefore, I will begin at theì
beginning.  Since time and energy are in short supply, however, I will notì
attempt to provide the same comprehensive documentation that I did forì
ARUNZ.  Instead, I will concentrate on the basics, on the one hand, and onì
some of the special features that many users may overlook, on the other.

Z-System Shells

     A Z-System shell is a program that takes over the user-input functionì
of the command processor.  The way this works is that the Z-Systemì
environment includes a special area in memory called the shell stack whereì
shell command lines can be kept.  Whenever the ZCPR3 command processor isì
finished processing all the commands that have been passed to it in theì
command line buffer (another special area in memory), it checks the shellì
stack.  Only if no command line is present there does the command processorì
itself prompt the user for the next command line.  If there is an entry inì
the shell stack, then that command line is run instead, and the user noì
longer sees the command processor directly.

     Some shells, like the EASE history shell, while making a big change inì
how the system is actually running, make relatively little change in how itì
appears to run.  A command prompt is still presented, and one entersì
commands more or less as usual.  The difference is that one has a moreì
capable editor at one's disposal, and the commands are saved to a historyì
file from which they can be recalled, edited, and run again.  As we shallì
see, the ZFILER shell presents the user with a dramatically different userì
interface.

What is ZFILER For?

     Historically, ZFILER is a descendant in the line of file maintenanceì
utilities like SWEEP and NSWP (hence the "filer" part of the name).  Fileì
maintenance is generally concerned with copying files, looking at theirì
contents, renaming them, erasing them, and so on.  ZFILER provides all theseì
functions and more.

     ZFILER's immediate parent was VFILER, where the "V" stood for video. ì
The TCAP facility in Z-System makes it easy for programs to take advantageì
of the full-screen capabilities of whatever video display terminal happensì
to be in use at any time.  In contrast to applications under CP/M, Z-Systemì
programs need not be configured to match the terminal.  It was, therefore,ì
natural to build a file maintenance program in which the files are displayedì
graphically on the screen.  When I decided to explore some new directionsì
with VFILER, to avoid confusion I gave the program the new name ZFILER, forì
Z-System Filer.

     The file maintenance tasks described above would not require a shell. ì
Making the program a shell, however, allows it to go beyond the functionsì
included in the program's own code.  Because a shell can pass command linesì
to the operating system, ZFILER can perform any operation that the computerì
is capable of.  Like a menu system, however, it helps the user by generatingì
the commands automatically at the touch of a key.

     When ZFILER is running, the screen is filled with an alphabetizedì
display of the files in a specified directory, and there is a pointer thatì
the user can manipulate using cursor control keys.  If we had a mouse toì
move the pointer, it would be a little like having a Macintosh.  Actually,ì
it would be a lot more.  It would be like having a mouse with fifty buttons! ì
Once the pointer has been positioned on a file, pressing a key (or two orì
three) causes any of a great number of functions to be invoked to act on that file.  We will describe how this works in more detail shortly.

Invoking ZFILER

     Since ZFILER performs full-screen operations, a proper Z-Systemì
terminal descriptor (TCAP) must have been loaded.  If you have not doneì
that, or if you have selected a terminal that does not support all theì
functions ZFILER needs, then ZFILER will give you an error message.  Theì
TCAP, unfortunately, does not include information about whether dim orì
reverse video is used by the terminal, and since these two modes forì
highlighting regions on the screen are so different, ZFILER is madeì
available in separate versions for each.

     There is also an option to have either four or five columns of fileì
names in the display.  Personally, I prefer the four-column version, whichì
gives an uncluttered screen with plenty of restful white space and a veryì
distinct, easy-to-spot pointer.  Others think it is more important to beì
able to see the maximum number of files on each screen and prefer the five-column display.

     Then there is the issue of support for time and date stamping of files. ì
ZFILER contains the code for preserving the time stamps when files areì
copied.  So as not to inflict the overhead of this code on those who haveì
not implemented DateStamper (though they should do that!), ZFILER is alsoì
provided in versions with and without the DateStamper code.

     If we supported all combinations of the above choices, there would beì
eight different versions of ZFILER.  Typically, the distribution libraryì
contains four or five of the combinations.  For example, a five-column fileì
display is not particularly compatible with reverse video highlighting,ì
because the reverse video of tagged files runs into the reverse-videoì
pointer.

     When you get ZFILER, you have to choose which version you prefer,ì
extract it for the distribution library, and give it a working name (some ofì
the early Z-System shells had to have a specific name, but you can giveì
ZFILER any name you like).  I prefer the name ZF, since it is very quick andì
easy to type, and I will use that name in all the examples that follow.

     The general syntax for invoking ZFILER is

        ZF filespec

where "filespec" is a standard Z-System ambiguous file specification (thatì
is, it may contain the wildcard characters "?" and "*").  The filespecì
selects the directory area and the files from that area to be included inì
the screen display.

     Various parts of the filespec can be omitted.  If no filespec is givenì
at all, then "*.*" for the currently logged directory is assumed. ì
Similarly, if only a directory is specified (e.g., B: or 3: or B3: orì
WORK:), then all the files ("*.*") in that directory are displayed.  If aì
file name/type is included, then it will serve as a mask on the files to beì
displayed.  Thus "ZF WORK:*.DOC" will show only files of type DOC in theì
directory WORK:.

     The directory and file mask can both be changed from inside ZFILER asì
well using the "L" or LOG command.  I bring this up now because there is aì
confusing difference in the way the "L" command works.  VFILER originallyì
allowed one to change only the directory and not the file mask from insideì
the program.  To save the user the trouble of typing the colon after aì
directory, its inclusion was made optional.  Since users became soì
accustomed to this shorthand, it was carried over into ZFILER.  Because ofì
this, if you want to change only the file mask, you must remember to precedeì
it with a colon.  Otherwise your mask will be taken as the name of aì
directory (which generally results in an error message).

     One brief aside for programmer types.  ZFILER can be loaded from anyì
directory.  One of the special features of Z-System since version 3.3 of theì
command processor allows a program to find out both its own name and theì
directory from which it was actually loaded, perhaps as the result of a pathì
search.  ZFILER builds the shell stack entry to invoke ZFILER under itsì
current name from the directory in which it is actually located.  Thisì
sometimes makes it run faster, and it allows ZFILER to be invoked from aì
directory that is not on the search path.

The ZFILER Display

     The main ZFILER display contains three parts.  At the top of the screenì
there is a message line.  In the version of ZFILER that is current at theì
time I am writing this column (version 1.0L), this line contains, from leftì
to right, the following information: (1) the directory that has beenì
selected, in both DU and DIR (named directory) format; (2) the indicatorì
"[PUBLIC]" if that directory is a ZRDOS public directory (if you don't knowì
what this is, just ignore it); (3) the current time of day if DateStamper orì
one of the new DOSs (ZSDOS or ZDDOS) is running; (4) the program's officialì
name and version; (5) the text string "Current File:"; and (6) the name ofì
the file currently being pointed to (this changes as the pointer is moved).

     At the bottom of the screen is a command prompt of the form

        Command? (/=Help, X=Quit):

The cursor (don't confuse this with the file pointer) is positioned afterì
this command prompt to indicate that ZFILER is waiting for you to press aì
key.

     The center 20 lines of the screen show the selected files.  Theì
character string "-->" (only "->" in the five-column display) floats betweenì
the rows of file names and designates the so-called "pointed-to" file.  Manyì
of the ZFILER commands automatically operate on this file.

     What we have described so far is the main ZFILER screen, but it is notì
the only one.  As the command prompt suggests, pressing the slash characterì
(or "?" if you prefer) brings up a help screen that summarizes the built-inì
commands of ZFILER.  This help screen replaces the file display but leavesì
the status line at the top and the command line at the bottom, except thatì
"/=Help" changes to "/=Files".  As you might, therefore, guess, pressingì
slash again will take you back to the file display screen.

     I do not know if anyone makes use of this feature, but all ZFILERì
command operations can be invoked from the help screen.  Although you cannotì
see the file pointer, you can manipulate it in the usual way, and you canì
tell what file you are pointing to from the name displayed at the upperì
right on the status line.

ZFILER Commands

     I am not going to attempt to describe all of ZFILER's commands, but Iì
will try to list most of them.  Basically, the commands fall into severalì
classes.

     One classification reflects where the code for the command resides. ì
There are two categories:

    A. Built-In Commands
    B. Macro Commands

Class A includes the functions for which the code is part of ZFILER.  Macroì
commands are like aliases in that they generate command lines that areì
passed to the command processor for execution.  These commands make ZFILER aì
shell.  In this column I will discuss only the built-in commands, and I willì
take up the more complex subject of macro commands next time.

     A second classification depends on what the command acts on.  Threeì
categories describe the object of the commands:

    1. the pointed-to file
    2. a group of tagged files
    3. neither of the above

We will begin the discussion with commands of class A3, resident commandsì
that do not perform any action on the files.

Pointer Commands

     Class A3 includes the commands that move the file pointer.  These areì
shown on the help screen, and I will not list them here.  One can move theì
pointer to the next file on the screen or to the previous one (withì
wraparound); up, down, left, or right (with wraparound); to the first orì
last file on the current screen; or to the very first or very last file ofì
those selected by the file mask.  One can advance to the next screen ofì
files or to the previous screen.  Obviously, some of these functions will beì
redundant in some cases, such as when all the selected files can fit on oneì
screen (think what happens when there is exactly one file selected).

     ZFILER learns from the TCAP the control characters sent by any specialì
cursor keys on the keyboard (provided they send a single control characterì
and provided the TCAP has been set up correctly), and it makes them generateì
the up, down, left, and right functions.  If the cursor keys generateì
control codes normally used for another function, then that function will beì
lost (the cursor keys take precedence).  That can cause problems.  Oneì
solution is to eliminate the definition of the cursor keys in the TCAP andì
simply use the default WordStar diamond keys for those functions. ì
Alternatively, one can patch ZFILER to use different keys for its ownì
functions, but this is not straightforward to do, and I will not describe itì
here.

     The "J" (Jump) command allows you to jump to a file that you name. ì
This is very handy when there are many files in the display or when the fileì
you want is not on the current screen.  Press the "J" key, and you will beì
prompted for a file name.  You do not have to enter the exact name.  ZFILERì
automatically converts what you type into a wildcard filespec, and it findsì
the first file that matches.  For example, if you enter only "Z" followed byì
a return, this is equivalent to "Z*.*", and ZFILER will move the pointer toì
the first file that starts with a "Z".  Similarly, if you enter ".D", ZFILERì
will move to the first file with a file type that starts with "D".

     The "J" function is very handy; however, there is more.  Many peopleì
are not aware that you may press control-J to repeat the same search andì
find the next matching file.  The search will wrap around from the end ofì
the files back to the beginning.  This function is not listed on the helpì
screen because I could not find room for it.

Other Non-File Commands

     Some other commands that do not act on files are: X, L, A, S, E, H, Z,ì
and O.  "X", as the command prompt reminds you, is used to exit from ZFILER. ì
Besides terminating the current execution of the program, it also removesì
ZFILER's entry in the shell stack (if it did not, you would just reenter itì
right away).

     We already spoke about the "L" (Log) command earlier.  The "A"ì
(Alphabetize or Arrange or Alpha sort) toggles the way in which the filesì
are sorted, namely alphabetically by the file name or by the file type.      ì
The "S" (Status) command prompts you for a disk drive letter and then tellsì
you the amount of space remaining on that disk.

     The "E" command (refresh scrEEn -- I know that's stretching things, butì
"R" was already used) redraws the screen.  You might think that this wouldì
never be needed, but there are two circumstances in which it comes in veryì
handy.  One is when ZFILER is being used on a remote system.  It is trueì
that very few RASs make ZFILER available, but I do on Z-Node #3.  If you getì
some line noise, the screen can become garbled.  Then the "E" key can beì
used to draw a fresh screen.

     The other circumstance in which the "E" command saves the day is withì
Backgrounder-ii if you do not have a screen driver (I don't for my Conceptì
108 terminal -- never got around to writing one, partly because all theì
programs I use frequently have a redraw key like this one).  I simply defineì
a BGii key macro specifying "E" as the "redraw" key, save the keyì
definitions to ZFILER.BG, and attach that definition to ZF.COM.  Thenì
whenever I swap tasks back into ZFILER, BGii simulates my pressing the "E"ì
key, and the screen is redrawn.  This often gives a faster screen refreshì
than one gets with a full-fledged screen driver.

     The "H" (Help) command generates a macro command to invoke the Z-Systemì
HELP facility.  To tell the truth, I have not used this and don't evenì
remember precisely what it does.  I would have to look at the source code.

     The "Z" (Z-system) command prompts you for a command, and whatever youì
enter is passed on to the Z-System multiple command line buffer forì
execution.  When that command line is complete, ZFILER is reinvokedì
automatically.

     When you use the "Z" command, you will normally be logged into theì
directory that is currently displayed.  However, this will not always beì
possible.  ZFILER allows you to select directories with user numbers from 0ì
to 31.  Unless you are using a version of ZCPR33 or ZCPR34 with the HIGHUSERì
option enabled, you cannot log into user areas above 15.  In that caseì
ZFILER will put you in the directory your were in when you invoked ZFILER. ì
In any case, the command prompt will indicate the directory from which yourì
command line will be executed.

     Since commands you run using the "Z" function may put some informationì
on the screen that you would not want ZFILER to obliterate immediately,ì
there is a flag set that signals ZFILER to prompt you and to wait for you toì
press a key before putting up its display.  Here is a tip for advancedì
users.  If you enter your command line with one or more leading spaces, thisì
shell-wait flag will not be set, and ZFILER will return without your havingì
to press a key.  The leading spaces are stripped from the command lineì
before it is passed to the command processor.  This means that you cannotì
use a leading space to force invocation of the extended command processorì
(ECP); you have to use the slash prefix instead.  A space and a slash willì
force invocation of the ECP and will disable the shell-wait flag.

     The final command in class A3 is the "O" (Options) command.  It is aì
complex topic, and I will leave it for next time.  If you can't wait untilì
then, experiment with it.  It should not be able to do any harm to yourì
system.

Single-File Built-In Functions

     Now let's discuss the commands in class A1, the built-in commands thatì
act on the pointed-to file.  These are invoked by pressing one of theì
following keys, whose meaning is indicated in parentheses: C (Copy), Mì
(Move), D (Delete), R (Rename), V (View), P (Print), F (File size), T (Tag),ì
and U (Untag).  Some of these are self-explanatory, and I will not discussì
them.

     The "C" command copies a file to another directory under the same name;ì
it does not allow one to give a new name for the destination file (however,ì
you can do that with a macro command).  The "M" command does not really moveì
a file; it copies the file and then, if the copy was successful, deletes theì
original file.  It is really a combination of "C" and "D".  Moving a fileì
this way is inefficient if the destination directory is on the same drive asì
the source file.  A macro command that invokes an ARUNZ alias can get aroundì
this limitation (and almost all other ZFILER limitations).

     The tag and untag commands are used to select a group of files on whichì
operations can be performed.  Tagged files are indicated in two ways.  Aì
special character ("#") is placed after the file name in the display, and,ì
if the terminal supports video highlighting, the file is highlighted.

     Two related commands are W (Wild tag) and Y (Yank back?).  "W" allowsì
you to tag or untag groups of files designated by an ambiguous file spec. ì
After tagged files are operated on by the built-in group commands describedì
below, the tag marker "#" is changed to "'" (a soft tag).  The "Y" commandì
changes the soft tags back into hard tags so that further group operationsì
can be performed on those files.

Built-In Group Commands

     Group commands are initiated by pressing the "G" (Group) key.  Theì
command prompt at the bottom of the screen changes to

    Command? (/=Help, X=Quit)  Group: (A,C,D,F,M,P,R,T,U,V)

For now we will consider only the built-in group functions (class A2) andì
will take up group macro commands (class B2) next time.

     Except for the four functions described below, the letters invoke theì
same action as the individual command corresponding to that letter, but theì
function is performed on all the tagged files.  We will not discuss thoseì
further.  Note in particular that the keys "A" and "R", however, have aì
group function that is completely different from the individual function.

     The "U" and "T" group functions do not act on the tagged files; theyì
change the tagging.  The former untags all files; the latter tags them all.

     The "R" group function is another one that does not, strictly speaking,ì
act on the tagged files.  It reverses the tags, tagging the files that hadì
been untagged and untagging the ones that had been tagged.  This can be veryì
handy in several circumstances.  For example, you might want to copy all theì
files except two.  It is easier to tag those two and then to reverse theì
tags.  As another example, you might want to copy some of the displayedì
files to one diskette and the others to a second diskette.  I do thisì
frequently.  I begin by tagging the ones to go to the first diskette.  Thenì
I group copy ("GC") them to the destination diskette.  Next, I yank back theì
tags using the "Y" command and then reverse the tags with "GR".  Now I canì
group copy the rest to the second diskette.

     The "A" (Archive) group command is very handy for automating backups. ì
When it is entered, the tags are removed from any tagged file whose archiveì
flag is set.  As a result, only files that have been modified since the flagì
was last set will remain tagged.  In addition, the "A" group commandì
automatically initiates a group copy operation but with one special feature. ì
After the file has been copied successfully, the archive flag on the sourceì
file is set to indicate that the file has been backed up.

     Under later versions of VFILER, the group "A" command automaticallyì
tagged all unarchived files; under ZFILER it untags the archived ones.  Thisì
difference is very important.  With VFILER, you were forced to back up allì
the files selected by the VFILER file mask.  Under ZFILER you can select theì
files that will be candidates for backing up.  If you want the achieve theì
same function as under VFILER, just tag all the files first with "GT" andì
then archive them with "GA".  On the other hand, if you want to exlude BAKì
files from the backup, you can "GT" all files, untag the "*.BAK" files usingì
the "W" command, and then use the "GA" command.

     After you enter the command "GA", you will be prompted for aì
destination directory.  You do not have to supply one!  If you simply enterì
a carriage return, the copy operation will be skipped, and you will be leftì
with tags on the files that need to be backed up.  You can then use a macroì
function to back them up in a specialized way, such as crunchingì
(compressing) them to the backup disk (instead of copying them as they are)ì
or putting them into a library on the backup diskette.  Next time we willì
discuss the macro techniques required to do this.