ezab066@CHPC.BRC.UTEXAS.EDU.UUCP (02/20/87)
>> Someone recently said it was 'sad' that SET DEFAULT does not >> complain when you set to a non-existent directory. >> >> 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 [] >> ... >> Checking whether a directory you're setting to exists is easily >> done in a command procedure... Setting default first to a nonexistent directory and then create the directory tree is illogical to me. In the first place, how do you know that you want to create such a new directory tree without knowing what directories you already have existing. The new subdirectories that you're creating might possibly be something similar to what you already have. You don't want to confuse yourself by creating a lot of vaguely different sub-directories, do you ? It's more logical to first look at a directory tree. Then, decide if the new file fits in any of the existing sub-...-directories. If it does not, then you create the new sub-...-directory. 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. ------------------------------------- Albert Wu ARPANET: EZAB066@CHPC.BRC.UTEXAS.EDU BITNET: EZAB066@UTCHPC.BITNET ------
McGuire_Ed@GRINNELL.MAILNET.UUCP (03/02/87)
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
ted@cgl.ucsf.edu@blia.UUCP (03/03/87)
In article <8703030035.AA24496@ucbvax.Berkeley.EDU>, McGuire_Ed@GRINNELL.MAILNET writes: > 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' Better would be to have DEC add a qualifier such as /MUSTEXIST. Without it, SET DEFAULT works as now so we don't break any .COM files. If you like UNIX, do "CD :== SET DEFAULT/MUSTEXIST" and then it yells at you if you CD to a non-existant directory. Symbols, unlike command files, are cheap! =============================================================================== Ted Marshall Britton Lee, Inc. p-mail: 14600 Winchester Blvd, Los Gatos, Ca 95030 voice: (408)378-7000 uucp: ...!ucbvax!mtxinu!blia!ted ARPA: mtxinu!blia!ted@Berkeley.EDU disclaimer: These opinions are my own and may not reflect those of my employer; I leave them alone and they leave me alone. fortune for today: "He is now rising from affluence to poverty." -- Mark Twain