home *** CD-ROM | disk | FTP | other *** search
- Library Shell (LSH) Proposal
- Jay Sage
- January 2, 1987
-
-
- This document is a proposal and preliminary specification for a library
- shell program whose purpose is to simplify operations performed with files
- in libraries. It has been given the tentative name LSH. As usual, I
- eagerly solicit comments from the user community about this proposal. If
- you have any suggestions to offer, I can be contacted directly by mail,
- voice phone, or modem as follows:
-
- Jay Sage voice phone: 617-965-3552
- 1435 Centre Street z-node #3: 617-965-7259
- Newton Centre, MA 02159 (please do not confuse the numbers!)
-
- I also try to log into the Ladera Z-Node #2 in Los Angeles and the Lilliput
- Z-Nodes in Chicago fairly often. In addition, other sysops who have PC-
- Pursuit service may be willing to forward comments to me.
-
-
- Program Overview
- ----------------
-
-
- In order to afford virtually limitless flexibility to the user, the program
- would work with a user-written script file LSH.CMD that combines the alias
- script expansion feature of the ARUNZ script file ALIAS.CMD with the menu
- (help) display of the VFILER/ZFILER macro files VFILER.CMD/ZFILER.CMD.
-
- The program would have two logical sections, one that would come into play
- when the shell program is invoked by the user and one that would come into
- play whenever the shell is invoked automatically by the command processor.
- Each of these sections is described below.
-
-
- Manual Invocation
- -----------------
-
-
- 1. Syntax: LSH DIR:UFN.LBR run shell on designated library
- LSH DIR:UFN run shell on library DIR:UFN.LBR
-
- Any invocation that does not match one of these forms (e.g., no file
- name, an ambiguous file name, an explicit type other than LBR, or more
- than one parameter on the line) would cause an abort with a display of a
- built-in syntax help screen.
-
- 2. If the invocation has a valid form, then the program would build a shell
- stack entry in the following way:
-
- a. The first bytes of the shell stack entry (bytes 00-08h) would
- contain the name of the shell from the external file control block
- (or the default name LSH) padded with spaces and followed by a null.
- This is the only part of the shell stack entry that is interpreted
- as a command line by the command processor. All other information
- needed by the shell will be coded into the part of the shell stack
- after the null, where it can be kept in any convenient form,
- including binary. No DU: or DIR: prefix is put before the shell
- name in order to avoid any problems in systems that do not allow
- either (or both) of these forms. Consequently, the shell program
- must be accessible along the path.
-
- b. The name (only) of the requested library (8 characters) will be
- saved in the shell stack entry (bytes 09-10h).
-
- c. The drive and user numbers for the directory containing the
- requested library would be stored as a binary word (bytes 11-12h) in
- the format used by LOGUD and similar subroutines in SYSLIB. The
- parsing required to get this information and to enforce security is
- handled entirely by the command processor when it builds the default
- file control block. The shell just has to pick up the values from
- the default file control block and store them.
-
- d. Any other configuration information that is to be preserved from one
- execution of the shell to the next can be saved using the remaining
- bytes in the stack entry (13-1fh, typically, are available). I
- cannot think of any such information now, but I am sure that will
- change.
-
- 3. The code would verify the presence of an available shell stack entry
- with adequate capacity for the required information. If the necessary
- support is not present, the program will abort with an appropriate error
- message.
-
- 4. Next, the program would check for any pending commands in the command
- line buffer. If there are any, control would be returned to the command
- processor. Otherwise, control would be passed to the shell part of the
- program as described below.
-
-
- Shell Invocation
- ----------------
-
-
- When the program has been invoked as a shell by the command processor, the
- following actions should be taken:
-
- 1. Record the current directory (DU$ORIG as in VFILER/ZFILER) so that it
- can be restored on exit. If one wants to be sure to return to the very
- original directory, no matter what other directories may have been
- logged in as the result of commands passed through the shell, one could
- keep this original DU in the shell stack entry.
-
- 2. Open the LSH.CMD file containing the command-line scripts to be
- generated by LSH. A configuration flag can determine whether this file
- is searched for along the entire path or only in the root directory. If
- the file is not found, the program would abort (remove its shell stack
- entry) with an error message.
-
- 3. Get the directory of the requested library from the shell stack entry
- and log it in.
-
- 4. Get the library name from the shell stack entry, construct a file
- control block, and try to open the file. If the library is not found,
- abort the shell (remove the stack entry) and give an error message.
-
- 5. Get the directory of the library and display it. If the file is not a
- valid library or if TPA overflow occurs when trying to form the
- directory, abort with an error message. (I think that the directory
- should be redisplayed every time control returns to the shell, since
- that is what most users I have observed do with LUX. As with ZLUX25 the
- code for the directory display should, in the interest of speed, be part
- of LSH. Directories that are too large to fit in a single screen would
- have to be paged.)
-
- 6. A command prompt would be displayed for the user. One line would
- identify LSH (or whatever it is called) and indicate that one can exit
- by typing control-c or get help by typing '?' (or '/'). The next line
- (possibly after one blank line) would be a prompt for a command. The
- screen might have the following appearance:
-
- [ LSH Active: ^c=abort ?=help ]
- DU|DIR:LIBNAME.LBR>
-
- The DU would be included if allowed by the DUOK flag in the environment
- descriptor, and the named directory (DIR) would be included if there is
- a name associated with the directory.
-
- 7. A command from the user would then be processed as follows:
-
- a. If the command starts with a control-c character, then the shell
- would be aborted. The shell stack entry would be popped off the
- stack and an exit message displayed.
-
- b. If the command starts with a '?' character (or '/' character), the
- user-written menu section of the LSH.CMD file would be displayed (as
- with VFILER/ZFILER) to provide help to the user.
-
- c. If the command line includes any other verb, that verb would be
- searched for in the LSH.CMD file in the same way that ARUNZ scans
- the ALIAS.CMD file. That is, each line in the file (up to the
- menu) can have alternative matching verbs connected by equal signs,
- and each verb can be ambiguous. There could also be a default verb
- that would match any command from the user. Parameters would be
- parsed in the same way as with ARUNZ.
-
- d. There would be a few differences between the ALIAS.CMD and LSH.CMD
- scripts. First, with LSH there would be parameters to represent the
- name of the currently selected library file and its directory (name,
- drive, and user). To facilitate changing to another library, there
- would be a special character ('!' for example) that would indicate
- that a new library should be selected. Thus, for example, there
- could be a line in the LSH.CMD file
-
- LSH=LUX=ZLUX ! $1
-
- On encountering the '!' symbol at the beginning of the script, LSH
- would pop the shell stack entry, parse the first token into the
- first default file control block, and then transfer control to the
- part of LSH normally run when a user invokes LSH manually. This
- would be equivalent, therefore, to the script
-
- LSH=LUX=ZLUX shctrl pop;lsh $1
-
- but would not require loading any programs from disk.
-
- e. If the verb is found in the LSH.CMD file, then the script is
- expanded and passed to the multiple command line buffer. If it is
- not found, then the user's command is passed as entered to the
- command line buffer (if the implementor wants to defeat this, all he
- has to do is include a default script in the LSH.CMD file).
-