Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!GRINNELL.MAILNET!McGuire_Ed
From: McGuire_Ed@GRINNELL.MAILNET.UUCP
Newsgroups: mod.computers.vax
Subject: RE: CD to a Subdir Before Creating It
Message-ID: <8703030035.AA24496@ucbvax.Berkeley.EDU>
Date: Mon, 2-Mar-87 14:14:00 EST
Article-I.D.: ucbvax.8703030035.AA24496
Posted: Mon Mar  2 14:14:00 1987
Date-Received: Tue, 3-Mar-87 21:40:56 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 71
Approved: info-vax@sri-kl.arpa

To: "info-vax" <info-vax@sri-kl.arpa>
Reply-To: "Albert Wu ( CEM-UT )" <ezab066@chpc.brc.utexas.edu>

> >> I hope they don't "fix" this.  My common method of creating a
> >> new directory (since I'm almost always going to work in it very
> >> next thing) is:
> >>
> >> $ SET DEFAULT [.ONE.TWO.THREE]
> >> $ CREATE/DIR []
>
> Setting default first to a nonexistent directory and then create the
> directory tree is illogical to me. [. . .]
>
> [. . .] To show the directory tree with
> a command procedure, one must be able to identify all the directory
> files, and one must be able to check whether a file with type DIR
> is a real directory file, all within a command procedure.

The example given at the top is not a programming example, it is an interactive
example.  The response was written assuming that the example was part of a
command procedure.  The point being made by the first person is that there is
less to type if you do:

$ SET DEF [uncreated-dir]
$ CRE/DIR []

than if you do:

$ CRE/DIR [uncreated-dir]
$ SET DEF [uncreated-dir]

Now that this is cleared up, *Flame ON*

A number of people have suggested that if the standard VMS command isn't
good enough, then we should write a command procedure to do it `better'.
I have some objections to this attitude.  They ultimately stem from the
academic environment, which it is my business to support.  In particular,
most of the users don't know how to write command procedures.

1. If I write nifty COMs just for my own account, I find myself learning the
   idiosyncrasies of my own custom environment, and forgetting how the vanilla
   environment behaves.  It really makes me a less effective resource.

2. If I write nifty COMs for everyone, lots of bad things happen:
   - I have to maintain them
   - They aren't in the VMS docset, so it's hard to find them in the index :-)
   - Most students who go to another VMS site when they enter the workforce
     find themselves relearning DCL

3. COMs are more expensive than standard commands.  Every time someone uses
   one, file system overhead is incurred to open and close, and several lines
   of DCL are executed.  Just for illustration: Heaven help you if you replace
   the DIR command with a front-end!  On my system, DIRECTORY is often invoked
   more frequently than any other command.

4. DIGITAL is perfectly capable of improving the standard DCL environment,
   if we give them a clear message that it needs to be done.  Granted it takes
   time, but we end up with a better product, don't we?
   - `SET DEFAULT [nosuch]' could be modified to return a warning message for
     programmers, with a helpful message for novices such as `Directory does
     not exist--create it or choose another'
   - They could add `DELETE/DIRECTORY [obsoletedir]'
   - They could provide an easy way to test the directory bit in the file
     header, also for programmers
   - and on, and on . . .

*Flame OFF*

Ed McGuire
Grinnell College
MCGUIRE@GRIN2.BITNET