                           MS-DOS_Tips


Hi Folks!

I'd  like to share some of my time-saving tips in MS-DOS.   Since 
being  introduced  to the operating system some  time  ago,  I've 
spent  many hours attempting to develop ways to save  time  while 
programming.   Programming  involves the use  of  every  resource 
available from your PC.  When I refer to "PC" I am addressing any 
MS/PC-DOS  compatible computer.  The Public Domain has to be  the 
most informative source of ideas I have ever come across.  I will 
have to admit that 50% of my programming conceptions originate in 
the PD.  I contribute to the PD as much as the next guy so I feel 
using  the  resource  is  permissible.   My  point  is  that  for 
information and examples to follow, the PD is the place to  look.  
The electronic bulletin board network is the best source for  PD.  
With  the low cost of modems and the availability  of  incredibly 
feature-packed  modem programs in the PD (read: free), I  see  no 
reason not to plug in to the resource gold mine.  Unless you only 
occasionally  use your PC for applications programs only,  GET  A 
MODEM!

Throughout this article I will refer to MS-DOS synonymously  with 
PC-DOS.   Also, all references are to my Kaypro 286i system.   My 
drives  are  configured  as follows.  A and B  are  1.2  megabyte 
floppies.   C  and D are 21.5 megabyte hard disks.  Some  of  the 
procedures  outlined  below may not be suitable for  360K  floppy 
based  systems.  I do also use all the procedures outlined  below 
on my Kaypro 16.  A and B are 360K floppies.  C is a 10  megabyte 
hard  disk.   I think the Kaypro 16 is the most  popular  of  the 
pseudo-16 bit Kaypro systems so the procedures will apply to it.

MS-DOS has this great built-in facility called batch  processing.  
In the old days (two years ago?) batch processing referred to the 
use  of a main-frame computer in slices of time.   All  processes 
needing CPU time were bundled together on punch cards and all fed 
in  at  one time.  They were  sequentially  processed  generating 
corresponding  output  or files and then the next member  of  the 
batch was processed.  There was no benefit of interactive use  of 
the  computer.   You had one chance to get it right or  else  you 
resubmitted  the  whole  batch  again the  next  day.   With  the 
introduction of the personal computer, interactive utilization of 
the  machine is possible.  But with all this technology, we  find 
ourselves in redundancy sometimes.  There is a way out.

Many sequences of commands are used daily by the operator in  MS-
DOS  that can be batched together.  There are two simple ways  to 
create  a batch file.  One is to use a text editor.  I use  EDLIN 
just  because of it's simple command set and small size and  fast 
speed.  Believe me, it's not much of an editor for anything  more 
than  that.  The other way is by device redirection.   Here's  an 
example:
     C:
     CD \FRED
     MARTHA

If  you  entered  this  list  of  commands  into  a  file  called 
HARRY.BAT, every time you typed HARRY at the DOS command  prompt, 
the  COMMAND.COM  resident  processing  system  would  read   the 
commands  from this file one line at a time.  First we would  log 
into  drive C.  Then change to the directory on that drive  named 
FRED.   Now the system would run a program named MARTHA.  If  you 
include  a program name after MARTHA, then as soon as  MARTHA  is 
through  running,  the COMMAND.COM processor remembers  you  have 
another command to execute and will do just that.  You can string 
these  things out as far as you want.  In fact, you can  use  the 
COMMAND /C command to load another COMMAND.COM processor and  use 
the DOS commands in it just like before.  Now as soon as you type 
EXIT at the DOS prompt, the first COMMAND.COM processor will take 
over  and  execute  the remaining commands.   I'll  give  you  an 
example:
     C:
     CD \FRED
     MARTHA
     COMMAND /C
     WP

Suppose  you  have  a file called DO-IT.BAT  on  your  disk.   It 
contains  the list of commands shown above.  Typing DO-IT at  the 
DOS prompt will log into drive C, change directory to FRED, run a 
program  called  MARTHA and as soon as MARTHA  was  finished  you 
would  see a DOS prompt.  You are not really where  you  started.  
You  are  now  within a second DOS command  processor.   You  can 
execute  any DOS command you want.  Now as soon as you  type  the 
command EXIT, you are returned to the first command processor and 
it  will pick up where it left off, executing the program  called 
WP.  This was a case of "nesting" the command processor.  In CP/M 
the equivalent of the command processor is called the CCP.   ZCPR 
was  a great attempt to help the user in CP/M to accomplish  some 
of the tasks available in DOS.

The  second  method of generating a batch file is  called  device 
redirection.  It's really a quite fast economical way to generate 
any  small file.  DOS treats everything it is connected to  as  a 
device.  The CRT, keyboard, disk drives, serial port etc. are all 
devices to DOS.  You have the ability to copy files, or  actually 
any data string, to and from the different devices.  You probably 
already know that any time you append a ">PRN" to a command,  all 
output  from the command is redirected to the printer.   You  can 
redirect  to  a file also.  ">FRED" appended to a  command  would 
send  all output from the command to a file called FRED.  If  you 
want to add (append) stuff to the end of an already existing file 
just use two ">"'s.  As in TYPE FILENAME.EXT >>FRED.  This  would 
send all printable characters sent to the screen to the end of an 
existing file named FRED.  These examples of I/O redirection  are 
fairly  popular and documented.  One type of redirection  is  all 
too  often  ignored.  COPY CON is a form of redirection  that  is 
handy  in  creating  small batch files.  If you  type  "COPY  CON 
FRED.BAT"  all  keys typed on the keyboard and generated  on  the 
screen  will  be  sent to a file named FRED.BAT.   You  have  now 
created  a batch file.  The return key will generate  a  carriage 
return  character in the file.  To end the redirection and  close 
the file use the end-of-file character CTRL-Z.  You can hold down 
the  CTRL  key  or use the F6 function  key.   Actually  all  the 
command accomplished was the copying of one devices output  (CON) 
to  another  device. (in this case the other device  was  a  file 
named FRED) (Is that anything like a boy named Sue?)

DOS users will tell you that there is one thing batch files  will 
not accomplish; the ability to run another batch file, then after 
it is finished, return to the originating batch file to  continue 
processing.  AHA!  Not true.  You can execute another batch  file 
as a "subroutine".  A subroutine, as defined in the Mike Stickney 
Fanatic Programmer's Manual, is a procedure, function or complete 
program called from another procedure, function or program; after 
which  a  return is made to the calling  procedure,  function  or 
program.  In other words, do something and come back when  you're 
finished.   If you use the COMMAND /C with a batch filename,  DOS 
will  load another command processor, execute the batch file  and 
as  long as the batch file has an EXIT command in it,  return  to 
the  point in the originating batch file after the  last  command 
issued.   The  syntax  (no, not a tax on sex,  but  the  required 
spelling,  etc.) of the command is "COMMAND command  /C".   Where 
"command" is any DOS command or batch filename.  Just remember to 
put the EXIT command in the called batch file.

Here's  a tricky one.  Have you ever wanted to have a batch  file 
go  to  another  directory, issue a command, and  return  to  the 
directory  area that it was called from?  Sure, you could  put  a 
"CD  \directory"  command  at the end of the  batch  file.   What 
happens when you call this batch file from another directory?  If 
your path is set properly, IE: multiple paths of which one points 
to the directory area where all your batch files are stored,  you 
can  call  your batch files from ANYWHERE in ANY disk  drive.   I 
figured out a way to accomplish a return to the calling directory 
area.   (I'll  admit I saw an article in the latest  PC  magazine 
that accomplishes this in a manner similar to mine, but I figured 
out  mine first!)  First I'll list the batch commands below  that 
accomplish this.  The commands are in a file named SAVDIR.BAT.

     DEL C:\BAT\RETDIR.BAT >NUL
     COPY C:\BAT\CD.TXT C:\BAT\RETDIR.BAT >NUL
     CD >>C:\BAT\RETDIR.BAT
     EXIT

This  list assumes a file already exists in C:\BAT named  CD.TXT.  
CD.TXT contains the characters "CD ".  I have my directory search 
path set up as follows:

     PATH=C:\DOS;C:\BAT;C:\;C:\NORTON;C:\UTILITY;C:\WP;D:\MOUSE

As  you can see, I have a path set to my C drive \BAT  directory.  
My \BAT directory contains all my batch files.  This way whenever 
I  need a batch file I need only type the batch command  name  at 
the  prompt.  DOS will search along the paths for  the  directory 
containing  the batch file.  This might get a little  complex  so 
please read this a few times until you understand it.  

The only other thing you need is the awareness that when you want 
the batch file to return to the calling directory area, you issue 
the  command RETDIR.  Now I'll outline what all this  mess  does.  
This  refers  to  the four line batch  file  listed  above  named 
SAVDIR.BAT.

Line  1)  Delete any file in the \BAT directory on  the  C  drive 
named  RETDIR.BAT.  This gets rid of any RETDIR batch  file  left 
over from the last use.

Line  2)  Copy  the contents of CD.TXT ("CD ") to  a  file  named 
RETDIR.BAT.   The  >NUL on the end sends all output  to  the  NUL 
device.   The  NUL device is just like it  sounds,  meaning  send 
output to never-never land.  In other words, don't clutter up the 
screen with crap when you don't have to.  Otherwise you'll see "1 
file(s) copied" and this might be confusing.

Line  3) Issue a CD command and append the output to the file  we 
created above.  Issuing CD by itself will cause DOS to print  out 
the curent disk and directory.  Since we redirected the output to 
the  RETDIR.BAT file, now we have a command in a batch file  that 
will take us back to where we originated.  All references to  the 
files  have  their full paths preceding them so  the  files  will 
always  be found in the same place.  The issuance of the  command 
"RETDIR"  will  cause the RETDIR.BAT file to  be  executed  which 
contains the command we need.

Line 4) EXIT back to the originating command processor.

The  only  thing you need be aware of at this point is  that  the 
SAVDIR   command  must  be  executed  as  a  child   process   of 
COMMAND.COM.   In  other  words  we need to  run  SAVDIR  like  a 
subroutine  so  that when the SAVDIR batch file is done,  we  are 
returned  to the originating batch file that has the commands  we 
needed to process in the first place.  This is done as  described 
earlier.  "COMMAND SAVDIR /C".  I have found one limitation  with 
this process.  It will not change the logged disk drive.  If  you 
call  this  procedure  from  drive D and  the  commands  you  are 
executing  take you to drive C, you will remain in drive C.   Now 
the SAVDIR/RETDIR stuff hasn't completely been wasted.   Whenever 
you  issue the CD command specifying a different disk drive,  the 
"default"  directory  on the drive will be changed  to  what  you 
specify.   Remember, when you type CD all by itself  DOS  outputs 
the drive and directory presently occupied.  Since we use the  CD 
command to generate our RETDIR batch file, the command  generated 
will  contain the disk drive prefix.  If all our  batch  commands 
keep  us  in the same drive, we're okay.   Changing  the  default 
directory of the drive you are presently logged into is the  same 
as logging into that directory.  If you do use this procedure  to 
migrate  from drive to drive, all you have to do after the  batch 
file  is done is change drives.  The originating  directory  area 
will be the one you are automatically dropped into.

As  you can see, you can make batch file processing as simple  or 
as  complex as you want.  With all the commands available to  you 
at  the  DOS  prompt, you really have  a  whole  new  programming 
language suitable for minor housekeeping chores.

                                      Mike Stickney, SYSOP - SKUG