Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!njin!princeton!phoenix!bernsten
From: bernsten@phoenix.Princeton.EDU (Dan Bernstein)
Newsgroups: comp.unix.questions
Subject: Re: Unix deficiencies/problems
Message-ID: <8200@phoenix.Princeton.EDU>
Date: 7 May 89 20:53:17 GMT
References: <810038@hpsemc.HP.COM> <810046@hpsemc.HP.COM> <159@dg.dg.com> <424@algor2.UUCP> <2656@mentor.cc.purdue.edu>
Reply-To: bernsten@phoenix.Princeton.EDU (Dan Bernstein)
Distribution: usa
Organization: Hmph.
Lines: 26

VMS lovers say that logical file names aren't available under UNIX.
Environment variables are used for particular functions within some
range of programs that understand the variable (so that EDITOR is a
widely understood variable naming an editing program, and BLTINPUT
is a variable understood only by program blt for command input);
the standard interfaces for opening a file do not check the environment
for filename subtitutions. Symbolic links are better but are stuck
within a particular directory and must be explicitly deleted.

The obvious UNIX solution is to put these functions in the shell.
Shell variables disappear at the end of a session, or you can put
them in a standard .-file; everything that VMS users want of a
logical file name can be done by appropriate shell features. None
of the standard shells have such features (though I remember someone
asking why filename ``blackhole'' seemed to act like /dev/null);
but it's a perfectly reasonable thing to put into forthcoming shells.
Then if someone really wants blackhole to be a non-directory-specific
logical file name pointing to /dev/null, it would be easy to set up.

Until someone provides a shell with logical file name features, VMS
lovers will keep laughing that UNIX can't do the job. After the shell
appears, we UNIX lovers will snicker at an operating system so
inextensible that adding a new feature requires rewriting the entire
system.

---Dan Bernstein, bernsten@phoenix.princeton.edu