GEMini Atari/GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso/files/bbs/fn132bin/fdman/chapter.11

Text File | 1991-09-03 | 13KB | 252 lines

Chapter 11:  Shells vs.  the Desktop                                     143




11  Shells vs.  the Desktop


   On the  Atari  ST, the  standard  environment is  the GEM  Desktop  (that
screen full of disk drive  icons, windows, pull-down menus and so on).   But
one may  also choose to run  the system by means  of a ``shell'' or  ``CLI''
(which stands for  Command Line Interface).   Instead of double-clicking  on
an icon  to run  a program,  you type its  name; instead  of dragging  icons
around to copy files,  you type a command like `cp file1 file2';  et cetera.
In this Chapter, we'll discuss how the choice of desktop  vs.  shell affects
the operation of Fnordadel.

   From  day  one,   the  Citadel  system  has  been  designed   around  the
command-line style  of operation,  and Fnordadel hasn't  changed this;  most
programs  in  the  distribution  take  arguments  on  the  command  line  to
determine  their behaviour.    This  is  antithetical to  the  mouse-driven,
interactive  philosophy of  GEM, but  it  doesn't mean  that you  can't  run
Fnordadel from the desktop.  You just have to kludge things around a bit.



11.1  Running from the Desktop

   There are a few  things you need to know.   Firstly, all the  programs in
the distribution come  with a `.tos' extender.   As with standard  ST usage,
this means  that the programs  use no GEM features  of any kind---just  TOS.
(As an  aside:  someone once  suggested that we  graft a GEM front-end  onto
citadel.  His body hasn't surfaced yet.).

   So,  what this  means for  desktop  users is  that double-clicking  on  a
Fnordadel program will  simply launch the program;  the program will not  be
supplied with any command-line arguments.  For some  programs, this is fine,
but for  others,  notably citadel,  it isn't.   The  solution?   Rename  the
programs to which you would like to supply arguments to  `program.ttp'.  Now
when you run  them from the desktop, a  dialogue box will pop up  asking for
the command  line arguments to be  supplied.  Type  them and hit `<CR>'  (or
click on `OK') to launch the program.

   This doesn't entirely  solve the problem,  because complex programs  like
citadel can take  far more parameters than can  be fit into the  small space
provided by  the GEM .ttp parameter  dialogue box.   Also, the GEM  dialogue
converts all the parameters  you type into upper-case before giving  them to
the program.   This is a Bad Thing  if the program in question  is expecting
lower-case values.   Fortunately, we've  tried to eliminate this problem  in
all Fnordadel programs by not checking case with parameters.

   There are  companies that  make enhancement or  replacement products  for
the  GEM Desktop,  such as  NeoDesk 3  by  Gribnif Software  and Hotwire  by
CodeHead Software.  Some of these products replace  the normal GEM parameter
dialogue with one that will accept more parameters,  or doesn't convert them
to upper-case, or  both.  It might  be worth your while to  investigate some
of these products if  you're having trouble using Fnordadel to  its fullest,
but  like working  in a  graphical, mouse-oriented  environment.   (We  have
never used  any of these  products ourselves, so  we're unable to  recommend
them.  However,  if you try them out  and find them useful, let us  know how
and why so we can record that fact in future versions of this manual.)



Chapter 11:  Shells vs.  the Desktop                                     144




   We've tried  to make all  of the programs  in the Fnordadel  distribution
decently desktop-friendly.   (Or, at least, not as blindingly  unfriendly as
before.)   They can  detect when they  have been run  from the desktop,  and
will always prompt  you to ``hit any key''  before they exit.   For programs
like clog, popular, et  cetera, this is a lifesaver.  (Note that  this ``hit
any key'' business is only from the desktop; if  you run a Fnordadel program
from a  shell, or from  a door within  Fnordadel, or  whatever, it won't  do
this.)


A desktop trick

   A trick  that used  to be popular  back in  the days when  people ran  ST
Citadels on tiny one-drive systems was to fool the ST  into thinking you had
two drives, in the following manner:

 1. Arrange  your files  so that  all of  your startup  stuff (auto  folder,
    `configur.tos',  `citadel.tos', et cetera)  is on  a disk marked  ``A'',
    and all of your BBS data files are on a disk marked ``B''.

 2. Edit `ctdlcnfg.sys'  to point #msgdir, #sysdir,  et cetera, at drive  B:
    rather than drive A:.

 3. Now  here's the  trick:   rename  the Fnordadel  binaries  from .tos  to
    `.prg' extensions.

 4. When  you boot from  disk ``A''  and run  citadel GEM will  pop up  that
    familiar ``Insert Disk B into Drive A'' box, and  off you go!  Fnordadel
    will work  as normal; the computer will  see the data files as  being on
    drive B:, but that's fine by us.

   A word  of  caution:   Many a  Sysop employing  this  technique has  come
home to  find his  BBS frozen at  a ``Please  insert Disk A  into Drive  A''
box.   Make sure that  all the directories  your system needs during  normal
operation start with B:\...  rather than A:\....  This includes  system file
directories  in `ctdlcnfg.sys',  directories  attached to  directory  rooms,
pathnames of files used to archive rooms, etc.

   Also note that  using this trick  requires naming all Fnordadel  programs
that  you intend  to  use (`citadel.tos',  `configur.tos',  utilities)  with
the  `.prg' extender.    Unfortunately, a  side-effect  is that  you can  no
longer supply any  command-line parameters to these  programs.  Some of  the
third-party GEM enhancements/replacements  referred to above may solve  this
problem by  letting you  have a  parameter dialogue  box for  use with  .prg
programs as  well as  .ttp ones.   Also,  Double Click  is rumoured to  have
released a neat hack to allow passing parameters to .prg programs.

   If you do run Fnordadel  from the desktop, be warned that  you're missing
out on  some stuff.   The primary thing  is that the  desktop has no way  of
catching return  codes from programs.    (Programs on the  ST may return  an
integer exit value  to the calling program;  it's a way of indicating  error
conditions and stuff.)   citadel makes use  of return codes to tell  you why
it is exiting; see also Chapter 7 [Events], page 93.

   The  bottom line,  then,  is  that  while  you  can hack  your  way  into
increased functionality when  trying to use Fnordadel from the  GEM Desktop,



Chapter 11:  Shells vs.  the Desktop                                     145




you won't ever be able to fully exploit the  system's capabilities until you
start using  a command shell of  some kind.   If you're interested in  doing
so, read on.



11.2  Running from a Shell

   If your  system has a  hard disk,  using a  shell is highly  recommended.
One reason for  this is the concept of  the ``path'', a list  of directories
you define  that tells the shell  where to look  for programs that you  wish
to execute.    Thus you  don't have  to know  which directory  a program  is
in  to run  it,  as long  as  the directory  is  on your  path.    Some  GEM
enhancements/replacements  offer a  similar function  (e.g.   Hotwire),  but
you  have  to set  things  up  a program  at  a  time, and  then  call  them
using ``hot-keys''  from the Desktop.    Is it easier  to remember to  press
Control-Alt-F7 to run citadel, or to simply type `citadel' and hit return?

   If  you've  got  only  floppies,  we  still   recommend  using  a  shell,
especially if you  have 1MB or more  of RAM. (If you  have 512K of RAM,  get
an upgrade; they're  cheap and you'll be glad you  did.)  It will  make life
easier.   Both  Fnordadel developers  are fans  of the  public domain  gulam
shell.   It's  what we use  full-time; our  systems auto-boot straight  into
gulam, so about  the only time we see  the GEM Desktop is if  gulam crashes.
Fortunately, that's  rare.   If you want  a copy of gulam,  let us know  and
we  can supply  you with  one, or  just  ask around  your local  area---it's
everywhere.

   There  are  many  reasons  to use  a  shell  to  run  Fnordadel.     Some
were mentioned  above:   to supply  more parameters  to programs;  to  avoid
parameter  conversion to  upper-case  (although  some shells  do  this  too,
notably pcommand and command.tos);  to avoid having GEM erase the  output of
a program before you  can see it; etc.   A further benefit of gulam  is that
it has a built-in  version of the powerful microEmacs text editor,  which is
very handy for people who frequently edit text files.

   However, we  think the  main reason  you'll want  to use a  shell to  run
Fnordadel is  that shells  can catch  the values returned  by programs  and,
with most  shells, can be  setup to do different  things depending on  which
code was returned.  You'll want to use this  in conjunction with events (see
Chapter 7 [Events],  page 93), because  each event causes Fnordadel to  exit
with a different  specific code.  You'll also  want to use this even  if you
have no events  defined, because citadel itself  uses a few result codes  to
indicate different exit conditions.

   We  have included  a  sample  gulam  shellscript called  `bbs.g'  in  the
distribution.   It's for managing the  overall operation of your system;  to
start up  your BBS with  it, simply  edit it as  required, put it  somewhere
pointed to  by your  PATH, and  type `bbs'.    The script  is reprinted  for
convenience below:

      set continue 1          # 'continue' flag
      set oldpath $path       # save the old path and set a new one
      set path c:\bin,e:\citmain,e:\citnet,e:\citutil,e:\
      cd e:\                  # change directory to where ctdltabl.sys lives



Chapter 11:  Shells vs.  the Desktop                                     146




      while { $continue > 0 }         # Loop until we set 'continue' to '0'

          if { -e ctdltabl.sys } == 0         # is ctdltabl.sys there?
              configur x                      # If not, reconfigure.
          endif

          citadel +line +ymodem +purge        # run citadel

          if { $status == 0 }                 # Did citadel.tos return '0'?
              set continue 0                  # If so, it was ^LQ from the
              echo 'Normal console termination.'      # Console.

          ef { $status == 1 }                 # Did it return '1'?
              echo 'Performing regular backup...'     # If so, it was a
              cp -R d:\secret\sys g:\backup   # defined Timeout (see the
              cp -R d:\secret\net g:\backup   # Reference Manual and
              cp -R d:\secret\audit g:\backup # ctdlcnfg.doc).
              echo 'Finished.'

          ef { $status == 2 }                 # Did it return '2'?
              set continue 0                  # It crashed. The file 'crash'
              echo 'Something must be buggered.'    # may help explain why.

          ef { $status == 3 }                 # Did it return '3'?
              set continue 0                  # That means someone used ^LQ
              echo 'Somebody took it down from remote.'       # from remote.

          ef { $status == 255 }               # Did it return '255'?
              set continue 0                  # **BOOM!**  Can try checking
              echo 'Something is REALLY* buggered.'   # 'crash', but....

          ef { $status == 15 }                # Here's another #event! This
              echo 'Exercising the feeping creatures...'     # one is for
              clog -t > d:\secret\library\userlog.sys        # nightly stats
              popular -msb > d:\secret\library\popular.sys   # gathering and
              callstat -c                                    # stuff like
              cp d:\secret\audit\callbaud.sys d:\secret\library # that...
              cp d:\secret\audit\callstat.sys d:\secret\library
          endif
      endwhile                        # ....and loop back to the top again.

      # if we reach here, it means that something up there set 'continue'
      # to '0', meaning we're supposed to quit.
      set path $oldpath               # Reset the path we had before
      unset oldpath                   # and remove the variable.
      # Done!

   Everything in the  above script should  be pretty much  self-explanatory.
Make  sure  that  path  is set  to  point  at  directories  containing  your
Fnordadel binaries; that way  you can type stuff like `callstat -c'  and the
shell will find  where callstat lives.   If you have another kind  of shell,
the same principles should apply, though the mechanics may vary.