home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / ZSYS / SIMTEL20 / DOC / LSHELL.DOC < prev    next >
Text File  |  2000-06-30  |  9KB  |  183 lines
  1.                         Library Shell (LSH) Proposal
  2.                                   Jay Sage
  3.                               January 2, 1987
  4.  
  5.  
  6. This document is a proposal and preliminary specification for a library 
  7. shell program whose purpose is to simplify operations performed with files 
  8. in libraries.  It has been given the tentative name LSH.  As usual, I 
  9. eagerly solicit comments from the user community about this proposal.  If 
  10. you have any suggestions to offer, I can be contacted directly by mail, 
  11. voice phone, or modem as follows:
  12.  
  13.         Jay Sage                        voice phone: 617-965-3552
  14.         1435 Centre Street              z-node #3:   617-965-7259
  15.         Newton Centre, MA 02159         (please do not confuse the numbers!)
  16.  
  17. I also try to log into the Ladera Z-Node #2 in Los Angeles and the Lilliput 
  18. Z-Nodes in Chicago fairly often.  In addition, other sysops who have PC-
  19. Pursuit service may be willing to forward comments to me.
  20.  
  21.  
  22.                               Program Overview
  23.                               ----------------
  24.  
  25.  
  26. In order to afford virtually limitless flexibility to the user, the program 
  27. would work with a user-written script file LSH.CMD that combines the alias 
  28. script expansion feature of the ARUNZ script file ALIAS.CMD with the menu 
  29. (help) display of the VFILER/ZFILER macro files VFILER.CMD/ZFILER.CMD.
  30.  
  31. The program would have two logical sections, one that would come into play 
  32. when the shell program is invoked by the user and one that would come into 
  33. play whenever the shell is invoked automatically by the command processor.  
  34. Each of these sections is described below.
  35.  
  36.  
  37.                              Manual Invocation
  38.                              -----------------
  39.  
  40.  
  41. 1.  Syntax:     LSH DIR:UFN.LBR         run shell on designated library
  42.                 LSH DIR:UFN             run shell on library DIR:UFN.LBR
  43.  
  44.     Any invocation that does not match one of these forms (e.g., no file 
  45.     name, an ambiguous file name, an explicit type other than LBR, or more 
  46.     than one parameter on the line) would cause an abort with a display of a 
  47.     built-in syntax help screen.
  48.  
  49. 2.  If the invocation has a valid form, then the program would build a shell 
  50.     stack entry in the following way:
  51.  
  52.     a.  The first bytes of the shell stack entry (bytes 00-08h) would 
  53.         contain the name of the shell from the external file control block 
  54.         (or the default name LSH) padded with spaces and followed by a null.  
  55.         This is the only part of the shell stack entry that is interpreted 
  56.         as a command line by the command processor.  All other information 
  57.         needed by the shell will be coded into the part of the shell stack 
  58.         after the null, where it can be kept in any convenient form, 
  59.         including binary.  No DU: or DIR: prefix is put before the shell 
  60.         name in order to avoid any problems in systems that do not allow 
  61.         either (or both) of these forms.  Consequently, the shell program 
  62.         must be accessible along the path.
  63.  
  64.     b.  The name (only) of the requested library (8 characters) will be 
  65.         saved in the shell stack entry (bytes 09-10h).
  66.  
  67.     c.  The drive and user numbers for the directory containing the 
  68.         requested library would be stored as a binary word (bytes 11-12h) in 
  69.         the format used by LOGUD and similar subroutines in SYSLIB.  The 
  70.         parsing required to get this information and to enforce security is 
  71.         handled entirely by the command processor when it builds the default 
  72.         file control block.  The shell just has to pick up the values from 
  73.         the default file control block and store them.
  74.  
  75.     d.  Any other configuration information that is to be preserved from one 
  76.         execution of the shell to the next can be saved using the remaining 
  77.         bytes in the stack entry (13-1fh, typically, are available).  I 
  78.         cannot think of any such information now, but I am sure that will 
  79.         change.
  80.  
  81. 3.  The code would verify the presence of an available shell stack entry 
  82.     with adequate capacity for the required information.  If the necessary 
  83.     support is not present, the program will abort with an appropriate error 
  84.     message.
  85.  
  86. 4.  Next, the program would check for any pending commands in the command 
  87.     line buffer.  If there are any, control would be returned to the command 
  88.     processor.  Otherwise, control would be passed to the shell part of the 
  89.     program as described below.
  90.  
  91.  
  92.                               Shell Invocation
  93.                               ----------------
  94.  
  95.  
  96. When the program has been invoked as a shell by the command processor, the 
  97. following actions should be taken:
  98.  
  99. 1.  Record the current directory (DU$ORIG as in VFILER/ZFILER) so that it 
  100.     can be restored on exit.  If one wants to be sure to return to the very 
  101.     original directory, no matter what other directories may have been 
  102.     logged in as the result of commands passed through the shell, one could 
  103.     keep this original DU in the shell stack entry.
  104.  
  105. 2.  Open the LSH.CMD file containing the command-line scripts to be 
  106.     generated by LSH.  A configuration flag can determine whether this file 
  107.     is searched for along the entire path or only in the root directory.  If 
  108.     the file is not found, the program would abort (remove its shell stack 
  109.     entry) with an error message.
  110.  
  111. 3.  Get the directory of the requested library from the shell stack entry 
  112.     and log it in.
  113.  
  114. 4.  Get the library name from the shell stack entry, construct a file 
  115.     control block, and try to open the file.  If the library is not found, 
  116.     abort the shell (remove the stack entry) and give an error message.
  117.  
  118. 5.  Get the directory of the library and display it.  If the file is not a 
  119.     valid library or if TPA overflow occurs when trying to form the 
  120.     directory, abort with an error message.  (I think that the directory 
  121.     should be redisplayed every time control returns to the shell, since 
  122.     that is what most users I have observed do with LUX.  As with ZLUX25 the 
  123.     code for the directory display should, in the interest of speed, be part 
  124.     of LSH.  Directories that are too large to fit in a single screen would 
  125.     have to be paged.)
  126.  
  127. 6.  A command prompt would be displayed for the user.  One line would 
  128.     identify LSH (or whatever it is called) and indicate that one can exit 
  129.     by typing control-c or get help by typing '?' (or '/').  The next line 
  130.     (possibly after one blank line) would be a prompt for a command.  The 
  131.     screen might have the following appearance:
  132.  
  133.                 [ LSH Active: ^c=abort ?=help ]
  134.                 DU|DIR:LIBNAME.LBR>
  135.  
  136.     The DU would be included if allowed by the DUOK flag in the environment 
  137.     descriptor, and the named directory (DIR) would be included if there is 
  138.     a name associated with the directory.
  139.  
  140. 7.  A command from the user would then be processed as follows:
  141.  
  142.     a.  If the command starts with a control-c character, then the shell 
  143.         would be aborted.  The shell stack entry would be popped off the 
  144.         stack and an exit message displayed.
  145.  
  146.     b.  If the command starts with a '?' character (or '/' character), the 
  147.         user-written menu section of the LSH.CMD file would be displayed (as 
  148.         with VFILER/ZFILER) to provide help to the user.
  149.  
  150.     c.  If the command line includes any other verb, that verb would be 
  151.         searched for in the LSH.CMD file in the same way that ARUNZ scans 
  152.         the ALIAS.CMD file.  That is, each line in the file (up to the 
  153.         menu) can have alternative matching verbs connected by equal signs, 
  154.         and each verb can be ambiguous.  There could also be a default verb 
  155.         that would match any command from the user.  Parameters would be 
  156.         parsed in the same way as with ARUNZ.
  157.  
  158.     d.  There would be a few differences between the ALIAS.CMD and LSH.CMD 
  159.         scripts.  First, with LSH there would be parameters to represent the 
  160.         name of the currently selected library file and its directory (name, 
  161.         drive, and user).  To facilitate changing to another library, there 
  162.         would be a special character ('!' for example) that would indicate 
  163.         that a new library should be selected.  Thus, for example, there 
  164.         could be a line in the LSH.CMD file
  165.  
  166.                 LSH=LUX=ZLUX ! $1
  167.  
  168.         On encountering the '!' symbol at the beginning of the script, LSH 
  169.         would pop the shell stack entry, parse the first token into the 
  170.         first default file control block, and then transfer control to the 
  171.         part of LSH normally run when a user invokes LSH manually.  This 
  172.         would be equivalent, therefore, to the script
  173.  
  174.                 LSH=LUX=ZLUX shctrl pop;lsh $1
  175.  
  176.         but would not require loading any programs from disk.
  177.  
  178.     e.  If the verb is found in the LSH.CMD file, then the script is 
  179.         expanded and passed to the multiple command line buffer.  If it is 
  180.         not found, then the user's command is passed as entered to the 
  181.         command line buffer (if the implementor wants to defeat this, all he 
  182.         has to do is include a default script in the LSH.CMD file).
  183.