hamm@BIOVAX.RUTGERS.EDU (04/25/87)
Bill Costa at UNH describes their SETUP utility. I found this interesting because it's nearly identical to a utility we implemented at the European Molecular Biology Lab (EMBL), for all the same reasons. (Actually, we borrowed the idea from someone at a British University - wonder how many other implementations there are?) Our version was called PREPARE (usually PREP). We did go through a couple of evolution cycles on the thing, though: By the way, the SETUP program is dirt simple. Right now it is simply a command procedure that, when asked to 'setup' the program FRED, will search a particular system directory for the file "FRED.SETUP". If the file does NOT exist, the user is told that there is no such command as FRED, and that they should check their spelling. If FRED.SETUP is found, it is simply "@'d". In other words, FRED.SETUP is itself a command procedure that will do WHATEVER IT TAKES to make FRED a command for the user. (For some programs, it may mean defining a dozen or so logicals and inserting the command into their DCL command table. For others, it may be as simple as defining a symbol; "FRED :== @UTL:FRED.COM"). The first change was that we wrote a program instead of a command procedure, because people usually put PREPAREs in their login.coms and got tired of waiting for them. We then had a file (called a "prepare dictionary") which contained a single-line command for each "prepare environment". Usually these were things like "@some.com", but they were also allowed to be SET COMMANDs or single definitions of some sort. Since the things were not required to sit in one directory, this also gave us a mechanism to provide global access to things the systems group were not maintaining - we'd just point the prepare command at some user's setup procedure, and let him/her do all the work. This worked well, but the list of environments grew, and the thing was again too slow. Finally we made the dictionary file indexed, and wrote a small PREPUTIL to add/remove things from it. This was less convenient than having just a text file, but sure was faster. As far as I know, this is the version they're currently running. By the way, all this "we" stuff I keep saying was mainly Roy Omond - I just watched and made helpful noises ("It's too slow, Roy!"). Whatever the implementation, I certainly agree with Bill that this is an ideal way to avoid defining everything for everyone. It also provides a lazy way out of the problem which occurs when two third-party packages define the same symbol differently. You just tell people to prepare only one of them at a time. (Beats workin'!) Who else has implementations of SETUP/PREPARE, and how do they differ from these two? Greg Hamm Director, Rutgers Molecular Biology Computing Lab hamm@biovax.rutgers.edu hamm@biovax.bitnet ------
CHRIS@ENGVAX.SCG.HAC.COM.UUCP (04/27/87)
>Who else has implementations of SETUP/PREPARE, and how do they differ from >these two? We do... Though after reading about the way that other people have this type of utility defined there has been some serious thought about redoing the way that it works! Our's is called SETUP, so in SYLOGIN.COM the DCL symbol SETUP is set to @PUB:SETUP. Currently SETUP is one big long command procedure with a bunch of labels. When a user issues a command like: $ SETUP TEX The DCL code fragment that they execute in SETUP looks like: $ on warning then goto No_Such_Setup $ if p1 .eqs. "" then goto Show_Available_Setups $ goto 'p1' : : : $ TeX: $ LaTeX: $ @TeX_Root:[Local]TexSetup $ if f$mode() .eqs. "BATCH" THEN goto Done $ define/user sys$input sys$command $ News/Directory TeX $ goto Done Note that this allows to point different names for the same setup at the same procedure. The problem with this approach is that even with abbreviated sections for each command, the SETUP command procedure quickly gets *very* long. Ours is 407 lines, and growing. It also contains product definitions for *every* system that we manage, so portions are never accessed on some systems. Personally I like the idea of having a short, simple command procedure that attempts to execute the first parameter passed to it. If you're tricky, you put the setup command files in a directory pointed to by a logical name that is a list. Then you can put your "normal" command files in the "every-system" directory, and the "local" command files in the "local" directory and let the system look in the local directory first and the every-system directory if it can't execute anything in the local directory. In some ways it's easier to manage, commands are trivial to add and remove simply by adding files to or deleting them from your system directory, though you do end up with a whole mess of little tiny command procedures cluttering your setup directory(s). I'm not quite sure what to say about the issue of speed... The approach outlined above will be quicker than one big long command procedure most of the time, but I really have no data or feel for how long it takes to add another command procedure onto the stack. I'm also not quite certain how one would get a program to be able to execute the setup command procedure *in the context of the current process* (it's easy enough to spawn of a command that executes the command file though). I don't believe that a parent processes symbols or Command Language Definitions can be modified from a subprocess. More ideas, thoughts, and musings on this subject are welcomed! I'd love to hear how other people deal with this issue. -- Chris Yoder UUCP -- {allegra or ihnp4}!scgvaxd!engvax!chris Hughes Aircraft Internet -- chris%engvax.scg.hac.com@ymir.bitnet Company ARPA -- chris%engvax.scg.hac.com@oberon.usc.edu