home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / admin / 6057 < prev    next >
Encoding:
Text File  |  1992-11-06  |  3.6 KB  |  87 lines
  1. Newsgroups: comp.unix.admin
  2. Path: sparky!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!pacific.mps.ohio-state.edu!neruda
  3. From: neruda@hydro.mps.ohio-state.edu (Steven Neruda)
  4. Subject: Re: how do other people deal with new man pages?
  5. In-Reply-To: vulture@imperial.ac.uk's message of Fri, 30 Oct 92 20:50:43 GMT
  6. Message-ID: <NERUDA.92Nov5143212@hydro.mps.ohio-state.edu>
  7. Sender: news@pacific.mps.ohio-state.edu
  8. Nntp-Posting-Host: hydro.mps.ohio-state.edu
  9. Organization: The HydroLab, The Ohio State University.
  10. References: <EJH.92Oct28092924@khonshu.colorado.edu> <Bwv3tz.A1s@mudos.ann-arbor.mi.us>
  11.     <1992Oct30.205044.21094@cc.ic.ac.uk>
  12. Date: Thu, 5 Nov 1992 19:32:12 GMT
  13. Lines: 72
  14.  
  15.  
  16. My site is kind of an amalgmation of a few of the previous ideas.
  17. I have a /usr/local{src,man,bin,lib} tree which I stick local stuff that is either
  18. a single program with a single man page or a small group of programs that
  19. is vital to life as we know it (tm).
  20.  
  21. For larger packages (X11R[45],ImageMagic, etc) I use a package based upon the tcl
  22. (tool control language interpreter, by John Furlani called modules.  The basic 
  23. package gets set up as an alias in one of the users dot files.  From then on 
  24. people can check what packages are available, get basic information about what
  25. happens when they load a package, load, unload packages with a simple command.
  26.  
  27. The high points of this system are:
  28.  
  29.     1) All meta files are stored in one location (/usr/local/packages in my case).
  30.  
  31.     2) Meta files are shell independant so there are only one meta file to write
  32.        for sh/ksh/csh/tcsh/bash.
  33.  
  34.     3) Meta files are human readable so people that want to run their own set of
  35.        modules can start from the systems wide.
  36.  
  37.     4) Ability to load/unload packages.  People can experiment without having to
  38.        logout and log back in again.
  39.  
  40.    5) Package specific tweaks like setting enviromental variable can automagically
  41.        take place for each package and get undated if package is moved.
  42.  
  43.     6) Modules can be marked for conflicts, exclusion, or issue warnings
  44.         when loaded/unloaded.  For example X11R4 and X11R5 are set up here so
  45.        a user can't load both at once.  If a user tries to unload 'base' they
  46.        are warned that life may get miserable if they do that and ask to confirm
  47.        their decision.
  48.  
  49. I have just phased in my new dot files with Modules.  So far my users are 
  50. extremely happy with them.  They don't have to know where something is or
  51. what special tweaks a package needs.  Instead they just type:
  52.  
  53.         module add ImagMagic
  54.  
  55. And all the programs from that package are available.  Another nice but necessary 
  56. hack just came up last week.  Our current version of the Wingz spreadsheet has
  57. a broken 'floating license'.  To work around this in a transparent manner I have 
  58. modified my "Wingz" package file to run it from the server and pop it up on the
  59. users workstation.  Users don't even know its broken and when its fixed I just
  60. change the module and they'll never notice.
  61.  
  62. I set up packages in /usr/local/packages/{NAME} with a bin/man and lib if 
  63. needed set up there.  Modules adds the proper path, man path, and any 
  64. other needed things.  Another nice things is if you set up your modules files
  65. carefully MANPATH and PATH will tend to be the same.
  66.  
  67. Sorry about the verbosity but since I hadn't seen a plug for Modules thought I 
  68. would.
  69.  
  70.             Steve
  71.  
  72.  
  73. Steve Neruda (neruda@mps.ohio-state.edu)
  74. Systems Programmer, The HydroLab (292-6193)
  75. 177 Scott Hall,  1090 Carmack Dr.
  76. Columbus, OH 43210
  77.  
  78.  
  79.  
  80.  
  81.  
  82. --
  83. Steve Neruda (neruda@mps.ohio-state.edu)
  84. Systems Programmer, The HydroLab (292-6193)
  85. 177 Scott Hall,  1090 Carmack Dr.
  86. Columbus, OH 43210
  87.