home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The C Users' Group Library 1994 August
/
wc-cdrom-cusersgrouplibrary-1994-08.iso
/
vol_100
/
177_01
/
shell.doc
< prev
next >
Wrap
Text File
|
1986-01-04
|
45KB
|
1,251 lines
-- DR. SHAW'S DOS SHELL --
User's Reference Manual 01/01/86
Introduction and Overview:
This document is meant to serve as a reference guide and
tutorial for the use of the Shell. It will be updated whenever
any of the planned quarterly modifications are actually
implemented in the Shell.
If you want to get directly to "The Right Stuff" in this
Manual and learn how to start or use the Shell, skip to the
sections "How to Start the Shell" and "How to Use the Shell".
Otherwise, read on.
Acknowledgements:
There are a number of people without whose support,
criticism and ideas the Shell would not have been possible. It
would be impossible to name all of them here since some of them
are people whose works I have read or whose programs I have used,
and provided influences in strictly an inferential and indirect
manner. I would, however, like to acknowledge those whose
suggestions and ideas, whether they realized it or not had the
most profound influence on the Shell's development:
Bob Leder
Chuck Sites
Christine Groat
Leor Zolman
Rick Rump
Elliot McGuire
Timothy Landgrave
Felix Kagi
Mark DeSmet
Joel Farley
Dedication:
To my friend, mentor and colleague, Bob Leder, whose many
suggestions I happily implemented, and who faithfully beta-tested
quite a number of early versions of the Shell, this User's
Reference Manual is dedicated.
1
Philosophy and History:
Every major program has its own Philosophy, or set of
principles upon which it stands. The quality of a program is
usually determined by how thoroughly those principles have been
defined and how effectively they were then implemented. The
current Shell is the end result of two programs: the original
idea, first attempted in late 1984, and the present result.
The original idea was not very well defined. I had grown
used to Rick Rump's Microshell product for CP/M systems, and when
I moved to MS-DOS/PC-DOS, I found the DOS command-line
interpreter just as lacking as the original CP/M CCP, upon which
it was based. The best capabilities I found in the DOS command-
line interpreter were those drawn from counterparts on UNIX
systems.
I decided to try to write a simple command-line interpreter
that would allow you to issue more than one command on the
command-line. I did NOT envision then writing a complete
interface to the operating system. As a result, the earliest
incarnation of the Shell was little more than a parser that
allowed multiple commands on the command-line, separated by semi-
colons. It was originally written with the Mark Williams' MWC86
C compiler in December 1984, and did NOT even allow proper use of
conventional DOS commands like DIR. It was only good for
running programs, occasionally.
The next revision, the first really usable one, was given
birth around early February, 1985, and featured usage of all DOS
commands, with the Shell first checking to see if what you typed
was a DOS command, and failing that, attempting to execute it as
a .COM, .EXE, or .BAT file respective (which is how DOS does it).
It also allowed review and re-use of the last 20 command-lines
thanks to Bob Leder, who added this touch one cold Saturday in
February, while I took his son sledding in Cherokee Park.
Written with Mark DeSmet's C compiler (which I still use), it was
with this version that I actually began to use the Shell in its
own development.
There were over the next 6 months a number of revisions that
included the UNIX-like commands, cp and ls, for copying files and
viewing directories, respectively. Also, a number (in fact, as
far as I know nearly all) of the prominent bugs were fixed,
including one that would mysteriously crash the Shell after a few
minutes, or hours usage. I slowly found them, the one bad one
teaching me to hesitate to use someone's not-so-well-debugged
public domain windows package (or any other kind of code, I
subsequently wrote my own).
The next major breakthrough, though, was when I stripped cp,
ls and several other commands out of the Shell and made them
external as opposed to internal commands. Not only did it make
the Shell more memory efficient (it still only uses 32-48k), but
I was able to incorporate the alias feature that gives any user
of the Shell the opportunity to implement his or her own
commands, with the same priority that DOS gives to its own
commands, and to even rename commands.
This subsequently led to the office-menu capability and the
sprucing up of cp and ls, not to mention the inclusion of several
new commands. I look forward to other programmers in particular
2
developing new commands for the Shell, and hope that they will
pass these back to me for redistribution so that we can all
benefit from them.
-------------------
The whole idea behind the Shell was to make DOS easier to
use, not harder! At the same time, I felt that offering a
strict menu-driven or icon-driven (like the Macintosh or 1-Dir)
interface, discouraged the advanced, "Power - User" (a la PC
Magazine). The Power-User is used to getting a lot done at one
time, and usually knows the next two or three commands he's going
to issue in advance. Therefore, the "single-step", "do this -
stop - then do this" approach of Menu- or Icon- driven interfaces
often becomes cumbersome and unproductive. Since it would be
nice to issue a whole series of commands to DOS, all at one time,
that was the first feature of the Shell to be implemented and
becomes the most obvious, immediate advantage to the new Shell
user.
The Shell, like DOS veriosn 2.00 and above, was written with
the hard-disk user in mind; this doesn't mean it won't work on a
floppy disk system, but just like DOS it runs infinitely better
on a hard disk system. With the price of hard disks what they
are (internal 20 meg under $ 700), I venture to say that the 2-
floppy-only system will become a thing of the past in a year.
I've tried to create an expandable ENVIRONMENT in the Shell,
to fit the needs every user of DOS. The Shell doesn't get in
the way (unless you have only 64K!), but instead enhances DOS.
I would like to see it enhanced further, and would like to
release quarterly revisions, whenever feasable (not unforseeable,
as I seem to generate some kind of improvement every couple of
weeks).
Anyway, I hope you like the Shell and find it as useful as I
have. I hope you'll give me some constructive feedback after
you've used it.
TradeMark Acknowlegements:
Listed below are the trademarks and their respective owners
for products referred to in this Manual:
Trademarks / Owner:
Microshell / New Generation Systems
CP/M / Digital Research
MS-DOS / MicroSoft
PC-DOS / IBM
UNIX / AT&T Bell Laboratories
MWC86 / Mark Williams Company
DeSmet C / C Ware
SideKick / Borland International
dBASE III / Ashton-Tate
IBM-PC / IBM
Compaq / Compaq Computer
WordStar / MicroPro International
3
A Word on Payware(tm), and User's obligations:
You'll see my Payware notice when you first bring up the
Shell. Like other user-distributed software, your obligation
only comes if you decide you want to use the Shell. I suggest
you try it, and it you like what it does, use it. Then, send me
the $ 25.00. If you don't use it, don't send me anything. I
don't expect you to pay for software that is not productive to
you. You can, however, give a copy of it to anyone you wish.
Just don't alter or remove the boot message (after all, you can
go around it, I tell you how in this manual).
I will offer paid users upgrades to future versions at
minimal or no cost, depending on the feasibility of the
distribution and the value of the upgrade. I do expect some
nice new features to be added by the end of the first quarter,
1986.
Hardware, Software and Memory Requirements
The Shell is designed to run on the IBM-PC, Compaq, or close
ROM-BIOS compatibles. It requires MS-DOS or PC-DOS version 2.0
or above. It uses a maximum of 48k of memory (verified by
executing the MEM command, loading another Shell on top of the
first, executing MEM again, and subtracting the difference in
available memory from the two MEM commands).
4
How to Start the Shell:
There are only a few steps to starting the Shell. If you
get an archived, squeezed or library version off of one of the
Electronic Bulletin Boards, you will need to unsqueeze it. Some
of the Bulletin Board versions provide .BAT files for installing
the Shell, so you may need only to run the appropriate .BAT file
to install everything.
Once this has been done, you will need to have the actual
Shell program file, SH.EXE in your current directory or in a
directory on the path (if you are not familiar with the DOS PATH
command, ask a cohort - barring this call me - barring that, last
but not least, read the DOS manual). It is also helpful to have
the file CONFIG.SH in the same place as SH.EXE, but not
essential. If you don't you'll get a warning message, but you
can go on.
I would suggest, though, that you study the file CONFIG.SH
(you can use your favorite word processor or text editor) and
become acquainted with its contents, because it is a key to your
being able to tailor the Shell and its commands to your needs and
it will be a focal point of future Shell development. I cover
this in more detail in the section "How to Use the Shell".
Anyway, if you don't have CONFIG.SH on your path or in the
current directory when you boot the Shell, put the Shell's
utilities (cp, ls, ...) in a directory on the path. BUT, to get
the maximum efficiency out of the Shell, put the utilities in
their own directory, and make sure that the lines in CONFIG.SH
give a complete path to the directory you put the utilities in.
For example, if you put the utilities in a sub-directory of the
root directory, called say, \SHBIN, then the line in CONFIG.SH
for a utility like cp might be:
cp=c:\shbin\cp.exe
This becomes even more interesting if you use a RAM disk.
Load all of the utilities into RAM (probably drive D) and the
line would read:
cp=d:\cp.exe or maybe cp=d:\shbin\cp.exe
if you have any sub-directories on the RAM disk.
Whatever you do, just make sure that each utility listed
with a full path to where it is located if you are going to use
the CONFIG.SH file.
Then just boot it up:
A>sh or C>sh
If you must get out of the Shell at anytime (most of the
time, you WON'T have to), just type EXIT and you'll be back at
good old (somewhat boring) DOS.
Before Bringing Up the Shell:
1. Set up any environment variables (PATH, etc.). (Future
versions will allow these to be changed from the Shell itself.)
2. Load any RAM-resident utilities.
5
How to Use the Shell:
Multiple Commands on the Command-Line
First off, the Shell you can execute as many commands as you
can fit on width of the screen. For instance, instead of:
C>dir
.
C>dir b:
.
C>ws
.
C>erase *.bak
.
C>cd\payroll
.
C>do payroll
.
C>cd\finances
.
C>lotus
you can do the same with:
dir;dir b:;ws;del *.bak;cd\payroll;do payroll;cd\finances;lotus
all you have to do is substitute a semi-colon on the
command-line everywhere you would ordinarily type a Carriage-
Return.
Editing the Command-Line
Made a mistake typing in that line? Editing is easy. Use
the following wordprocessing control keys to make changes to the
command line (the ^ represents the Ctrl key):
To move the cursor:
left: <- or ^S right: ^D or ->
word left: ^A or ^<- word right: ^F or ^->
To edit the command line:
delete character: ^G
clear field to right of cursor: - ^T
Backspace delete - Del
Insert mode on/off - Ins or ^V
Review and/or Re-edit the Command-Line
Or if you'd like to re-use and/or edit the previous 19
command lines, just browse through them with the up/down arrow
keys (or ^E and ^X), and press RETURN to run the selected line.
This makes repetitive tasks and mistakes easy to correct.
6
Commmands
The Shell supports most of the standard internal DOS
commands directly and in many instances has been observed to
perform them even faster than PC-DOS. Among those supported
directly are:
CLS, DEL/ERASE, REN/RENAME, RMDIR/RD, CHDIR/CD, and MKDIR/MD.
Also, two additional commands have been added:
MEM - shows total installed memory and total memory free.
RM - like erase or del.
Other internal DOS commands such as: COPY, DIR, DATE, TIME,
VER, VOL, <, >, and | are supported but use DOS to perform them.
Many of these have counterparts among the Shell's own set of
external commands, and these counterparts are often faster, more
productive and more useful than the DOS originals. Of course,
the big advantage is that you (or your programmer friends) can
add your own commands to the Shell, in a virtually unlimited
fashion.
The Shell is distributed with a set of external commands
that more than take the place of the original DOS versions.
Among these are:
LS - for Listing fileS and directories
MV - for renaming and/or moving a file to a different
disk location.
TYPE (or CAT) - for typing files
CP - for CoPying files
UNIQ - for removing duplicate lines of a sorted file.
CHMOD - for changing attributes of files to be:
read-only, hidden, system, or archival.
TEE - for splitting the output of a pipe or filter to
both the screen and wherever else you want.
These are described in detail on the following pages.
7
LS is a directory listing command, that is far more
informative and useful than DIR. For instance, here is the
output of LS with the -l option for the directory I am writing
this manual in:
d---- 0 Sep 09 10:09a 1985 [..]
d---- 0 Sep 09 10:09a 1985 [.]
d---- 0 Dec 13 01:24p 1985 [y]
----a 1152 Sep 09 10:10a 1985 autobio
----a 0 Jan 03 00:14a 1986 file
----a 12288 Oct 18 09:09a 1985 leor
----a 8832 Oct 22 08:20p 1985 leor2
----a 384 Oct 24 11:14a 1985 plauger
----a 7680 Dec 14 09:06p 1985 shell.doc
----a 2304 Dec 11 06:26p 1985 shell
----a 21632 Jan 03 00:04a 1986 shhelp.bak
----a 21760 Jan 03 00:14a 1986 shhelp.txt
----a 768 Sep 26 00:19a 1985 super.tl
----a 317 Dec 13 10:04a 1985 x
----a 122 Dec 13 01:25p 1985 z
# files: 15 # bytes: 77239 (90112) Remaining space: 3860480
The items on the left are file attributes, which show that
the first three files are directories (also obvious because LS
puts directory names in [ ]), and the remaining files can all be
archived by DOS's BACKUP. Each entry shows the file size in
bytes, the date and time of the last update along with the file
name. The default order is always alphabetical with the
directories 1st. The "# bytes" is the space taken by the files.
The figure in parenthesis is the real space taken up on the disk
(helpful since the hard disk files always use space to the next
8k on DOS 2 and the next 2k on DOS 3; and floppy files use space
to the next 4k). The remaining space is just that.
To use LS:
ls -fil *.dbf *.dif x*.com
where "-fil" is an example of the options for LS and the
rest are files with or without wildcards. Yes, you CAN give ls
more than one filename at a time (the "Remaining Space" figure is
based on the drive implied by the first directory/file-spec in a
list). As to the options which can be combined considerably:
-f: files (non-directories) only
-i: fast video, should not be used in redirection, but for
fast video output only (programmers: the 'i' is for int 10h)
-l: long format listing (like above, otherwise you get
filenames only)
-t: sort by date/time of last update
-r: reverse the selected sort order
-s: single column (name only) listing
-d: directories only listing
-c: columnar format
-p: show a page at a time (beats using the MORE filter!)
-?: message that shows how to use ls and the options
8
Since the Shell lets you make up and create your own
commands (listed in CONFIG.SH), a number of versions of ls have
been created without any effort at all and are referenced in the
CONFIG.SH file distributed with the Shell. Each one becomes
it's own independent command and does NOT require any programming
or expertise:
l - like ls, but with filenames only. (ls -li)
lc - like l, but in columns. (ls -ci)
lr - l sorted in reverse time of update order (ls -lrit)
(shows most recently updated files last)
LS is based on the UNIX command of the same name, but some
of the more creative ideas in it came from Mike Ouye's version
with DeSmet C, with tasty suggestions from Chuck Sites and Bob
Leder.
-------------------------
MV is another useful Shell command, that is primarily used
to MoVe a file from one directory to another, without having to
copy it. What MV does, is rewrite the directory entries
associated with a file, instead of making a copy of it elsewhere
on the disk. This saves the step of have to delete the original
copy of the file, and is much faster. It can also be used to
rename a file when a full pathname is involved. The present
version does NOT support wildcards. To use it:
mv \oldpath\filename \newpath\filename
which would move "filename" from the directory "oldpath" to
the directory "newpath".
-------------------------
The TYPE command in DOS has 3 counterparts in the Shell:
TYPE - just like the original, only faster.
TYP - just like TYPE with the MORE filter in use, in other
words TYPing a file will only put up one screenful at a time
until you press a key to continue.
CAT - for the UNIX afficiandos, the same as TYPE.
all of which are found in CONFIG.SH file as variations on
the CAT command.
With all three of these you can specify a sequence of files
to be printed on the screen:
type file1 file2....filen
TYPE does not accept wildcards.
9
CP is an external Shell command that not only lets you copy
one file to another file, but also allows you to copy an entire
list of files or directories at once. You can specify which
files in a group you do NOT want to copy, or you can give names
of directories whose files you want copied, and CP will expand
the directory-name to include every file immediately accesable in
that directory.
To just copy one file to another:
cp file1 file2
which will copy FILE1 to FILE2. To copy more than one file
in a list requires an understanding of what I call the "last
item" rule.
The "last item" rule in using CP is that the "last item" in
the list MUST be the destination, that is, where you are copying
the files to. For instance if you want to copy the files:
AUTOBIO, LEOR, SHELL in the directory listing above to a
directory called \PAYROLL:
cp autobio leor shell \payroll
The only time the "last item" rule is relaxed is when you
copy a single file specification to the current directory. Like
if you wanted to copy a file called EMPLOYEE.DAT from \PAYROLL to
the current directory, in which case the "last item" is implied
to be the current directory:
cp \payroll\employee.dat
or if you wanted all of the .DAT files in \PAYROLL to the
current directory:
cp \payroll\*.dat
Now you might think that to get ALL of the files in the
\PAYROLL directory, you would use:
cp \payroll\*.*
which would work, but cp will expand a directory name by
itself to directory\*.*, so that
cp \payroll
will do the same thing!
This means that if you want to copy all of the files listed
in the first example above, and all of the files in the sub-
directory Y (but not including its own sub-directories) to
\PAYROLL:
cp autobio leor shell y \payroll
10
In fact, you could even copy the files in directories called
\A, \B, and \C to a subdirectory of \PAYROLL called \D:
cp \a \b \c \payroll\d
(remember the "last item rule": the last item is the
destination to be copied to). If the destination you are
copying files to is the current directory and you have more than
one file in the list use '.' or ".\" to specify the current
directory. For instance, to copy the files in \A, \B, and \C to
the current directory:
cp \a \b \c .
or
cp \a \b \c .\
CP supports the use of wildcards ("*.*", "*" and "???") and
lets you specify which files should NOT be copied. Suppose you
want to copy all of the S*.TXT and L*.* files in the current
directory (listed by LS above) to a directory called ..\LTRS, but
you do NOT want to copy the file called LEOR2:
cp s*.txt l*.* !leor2 ..\ltrs
which says: "copy the s*.txt and l*.* files but NOT a file
called leor2 to a directory called ..\ltrs".
While it's copying CP will respond with:
copying shhelp.txt to ..\ltrs\shhelp.txt...completed
copying leor to ..\ltrs\leor...completed
Notice that the "leor2" file (from the directory listing
above) was not copied. Again, the "!" says do NOT include this
in the list even though you said "l*.*".
One big advantage to using CP in addition to being able to
get a whole bunch of files copied at once is that CP will use as
much memory as you have available on the machine for copying.
It will often read into memory an entire file (even 300-400k
files!) before writing the copy out to the disk, which means that
copying with CP can be extraordinarily fast!
Although its roots are found in the UNIX utility, cp, the
spirit of the current program can be found in the version that
Leor Zolman distributes with BDS-C.
11
UNIQ is a filter that removes duplicate lines of a sorted
file, and should be used like MORE with pipes or redirection.
For instance, in a batch file called MAKDIRS.BAT that Bob Leder
wrote:
cd \
tree | find "Path: " | repl "Path: " "md " | sort | uniq > %1
In this example, the output of the DOS TREE command is piped
to FIND, which looks for the phrase "Path: " and tells REPL (a
filter that replaces every occurance of one phrase in a file with
another) to replace every "Path: " with "md ", then calls SORT to
sort the file, and UNIQ to strip out any duplicate lines. The
end result is written to a file that you specify when you run
MAKDIRS, for instance:
C>MAKDIRS dirs.bat
and DIRS.BAT will now be capable of reproducing the entire
directory structure of your hard disk on another hard disk.
That's a long winded example of how to use UNIQ (and four billion
other things).
-------------------------
CHMOD is a command that is used to change a file's
attributes (the same one's shown on the left in the LS listing
above). With CHMOD you can set a file to be read-only (you
can't write over it), system or hidden (not found in standard
directory searches), or archival (able to be archived by DOS).
To use it:
chmod [+ | -] [rhsa] [filename]
where a '+' means turn on the attribute, and '-' means to
turn an attribute off. The "rhsa" are the various file
attribute combinations (r - read-only, h - hidden, s - system, a
- archival), and "filename" is the name of the file whose
attributes you want to modify.
As to a couple of simple examples, suppose you wanted (as I
like to do) to make your copy of COMMAND.COM on your hard disk
read-only, so you won't accidently erase it, or copy over the
wrong version (I would hate to smother it with a DOS 1.0
version!). You do this with:
chmod +r command.com
or perhaps you have a floppy disk formatted with the /s
(system) option, and you want to free up the space used by the
hidden files: ibmbio.com and ibmdos.com (which you can see listed
by LS):
chmod -rhs a:ibmbio.com
chmod -rhs a:ibmdos.com
CHMOD does not accept wildcards.
12
TEE is a program that is used in pipes to display on the
screen what is passing through the pipe. In the example above,
the batch file MAKDIRS.BAT, we can use TEE to display what is
passing through the pipe without interrupting the output of the
pipe itself:
tree | find "Path: " | repl "Path: " "md " | sort | uniq | tee %1
TEE is best used at the end of the pipe, as we have done
here. It will send a copy of the input to screen and another
copy to the file specified after it. In this case the file is
the one substituted by the variable %1.
-------------------------
Other DOS Commands
Before bringing up the Shell, you should have setup the
following DOS commands as you will want them to be: BREAK, PATH,
PROMPT, VERIFY, and SET. The key to remember here is that the
Shell is NOT a RAM-resident program like SideKick. It is
actually an application-program that interfaces with DOS to make
it easier to use. This means it is easy to get out of should
you need to, and cannot be accused of being incompatible with any
RAM-resident programs you might be using (plus this makes it less
buggy and easier for me to maintain).
Prompts
Currently the default prompt gives a full path to the
present working directory. Support for the conventional DOS
configurable prompt should be present in a future version.
13
Menu-Generation
The Shell has some simple menu-generation capabilities for
use in a office or automated enviroment. This means that you
can customize a machine to the point where both computer
illiterates (who might want Menus) and Power-Users (who will
typically like the Shell environment) can co-exist on the same
machine.
Menu outlines are kept in a file that is specified in
CONFIG.SH by an entry like:
menu=c:\menudir\menu.cfg
where "menu" is a key-word in CONFIG.SH, and in this
example, MENU.CFG is a menu configuration file found in the
directory called \MENUDIR. This is also the directory where the
menu-associated batch files are kept (for more information on
CONFIG.SH, see section "Adding Your Own Shell Commands").
To generate a menu, modify the menu configuration file (I'll
call it MENU.CFG in the examples here) to include a menu command
and a description for each item you want displayed on the menu.
The key is to have one command and description on each line in
MENU.CFG, in the form of command=descriptive phrase, where the
"command" is really the name of a batch file and therefore no
more than 8 characters. To generate a set of menu items like:
Payroll Run Payroll System
GL Run General Ledger
you would have the lines:
Payroll=Run Payroll System
GL=Run General Ledger
in MENU.CFG. Any line that does NOT have the '=' sign in
it will be centered and printed literally. To put a title on
the menu, enter the title line in MENU.CFG in the exact order
it will be displayed on the screen and:
Shaw*American Technologies Office System
blank
Payroll=Run Payroll System
GL=Run General Ledger
would generate a menu like:
Shaw*American Technologies Office System
Payroll Run Payroll System
GL Run General Ledger
Notice that the word "blank" as the first phrase on a line
means put a blank line on the screen.
For every entry in MENU.CFG with an '=' sign, you will
need to have a .BAT file that changes to that directory of your
system, and boots or loads the appropriate program. If the
Payroll entry above really ran a dBASE III system, then you will
14
need a batch file called PAYROLL.BAT that might have the
following in it:
echo off
cd\payroll
dbase payroll
cd\
Make sure that you place all menu related .BAT files in the
directory designated by the "menu=pathname" entry in CONFIG.SH as
I mentioned above.
To enable the menuing capabilities, bring up the Shell with
the -m option and the command "menu" (this can be done with
AUTOEXEC.BAT:
sh -m menu
The -m option enables menuing and tells the Shell to look
for a "menu=" entry in CONFIG.SH. If it is found, the Shell
will read the configuration file to generate a menu. The menu
will not be initially displayed until a "menu" command is issued
to the Shell, although that can be done when the Shell is brought
up (as shown above). You may choose to issue a "menu" command
later on. Issuing a "menu" command when the Shell was NOT
brought up with the -m option will NOT generate a Shell menu.
The Shell will automatically give precedence to a menu command
over other commands, and will always re-display the menu upon
exiting the .BAT file for that command. Also, a Shell menu will
always be redisplayed by entering the command "menu".
Try it, we use it in our office all the time!
Issuing Start-up Commands:
As shown above, the Shell will accept arguments on boot in
the following form:
sh -m cp \shbin\*.exe d:;menu
This example from my AUTOEXEC.BAT file will boot the Shell
with menu capabilities enabled, copy all of the .EXE files in
\shbin to drive d, and show the menu.
Another example might boot the Shell, change to a directory
called \UTIL (where utilities are kept), and show all of the
*.EXE files there:
sh cd\util;lc *.exe
15
Adding Your Own Shell Commands (featuring CONFIG.SH):
Probably one of the Shell's most powerful features is its
ability to reference commands by different names, and allow the
user (you!) to specify what a command should mean! In other
words, you can add your own commands to the Shell, which is
something DOS will NOT really let you do (barring the use of .BAT
files).
When the Shell is first brought up, it looks for a file
called CONFIG.SH in the present working directory (pwd) or on the
environment path. If the file is found, the Shell will read it
and from it initialize a set of internal commands and their
translation into real executable programs. Like the menu
configuration file, the statements in CONFIG.SH shoulbe be in the
form:
command=execution_string -options arguments
where "command" is the command you want to be able to use,
the "execution_string" is the full path and filename of a program
to be executed, "-options" are any additional options to be
passed, always beginning with '-', and "arguments" are any
additional parameters to be given.
For instance to get the output of LS every time you type DIR,
just enter the following line in CONFIG.SH:
dir=c:\shbin\ls.exe
where anytime you type DIR as a command, it will instead run
the LS program found in \SHBIN. You can do this with virtually
any command. You can also add your own as you write (or find)
other programs you would like to have as part of the Shell's
environment. There is also a speed advantage, as the Shell will
load and execute it's own set of commands via CONFIG.SH, faster
than it will others.
If you make a change to CONFIG.SH, you will need to exit the
Shell (just type "exit") and restart it for the new CONFIG.SH to
take effect. The next revision of the Shell will probably have
a command to re-initialize the commands from CONFIG.SH, without
having to leave the Shell.
Two keywords are reserved to have special meaning to
CONFIG.SH and should NOT be used for commands:
MENU=gives the path and name of the menu configuration file
and the path to the associated menu .BAT files.
LOG=gives the path to a directory where .LOG files will be
kept (see the section "Generating Logs of Shell Usage").
16
The following is my current CONFIG.SH:
menu=c:\shbin\config.shm
log=c:\shbin\logs
cp=d:\cp.exe
ls=d:\ls.exe -i
lc=d:\ls.exe -ci
l=d:\ls.exe -li
e=d:\e.exe
cat=d:\cat.exe -i
typ=d:\cat.exe -pi
type=d:\cat.exe -i
dir=d:\ls.exe -i
uniq=d:\uniq.exe
chmod=d:\chmod.exe
diff=c:\bin\diff.exe
lr=d:\ls.exe -lrit
mv=d:\mv.exe
To Quit the Shell
If at any time you want to get out of the Shell, just enter
the command "exit". This will return you to good old (yawn)
DOS.
17
Generating Logs of Shell (and therefore Computer) Usage
The Shell has the capability of maintaining a daily log of
computer usage. When the log-file option is enabled, every
command-line that you execute in the Shell will be written to the
log-file. One log-file is generated for every day the Shell is
used (provided the DOS system date has been properly set).
Multiple sessions on a given day are recorded sequentially in the
same log-file with a time-stamp showing the beginning of a new
session. A typical log (like this one named "12-12-85.log")
file might look like this:
23:25:09
l -d \shbin\*.*
l \shbin\logs\*.*
exit
23:29:20
cd\shbin\log
cd\shbin\logs
l
cat 12-12-85.log
time
ws
ws
ws
exit
23:32:08
ws
ws
exit
The times stamped into the log show that I started the Shell
on three different occasions (just before midnight). The Shell
automatically uses the system date to name log files, and because
the system date was set to 12-12-85, the log file was named "12-
12-85.log"
Log file capabilities are enabled in the Shell by starting
the Shell with the -l option. For instance to start the Shell
with the log-file enabled:
sh -l
or to start it with both log-files and menus enabled:
sh -lm
etc.
The log files are always kept in the directory specified by
the appropriate entry in CONFIG.SH:
log=c:\shbin\logs
in which case the log files will be kept in a subdirectory
of \shbin called (appropriately) "logs".
18
The End (for now).
(This page intentionally left almost blank.)
19
