VMS: logicals UNIX: links, but...

[Chris Torek]

In article <757 at mks.UUCP> tj at mks.UUCP (T. J. Thompson) writes:
>Programs that read and write ``known'' filenames like this are simply
>mis-designed.

Quite so.

>... it is true that some UNIX programs nonetheless do have built-in
>file names (yacc, for example; i know not why).

Because their authors goofed.  `Well known' names and defaults are
fine, as long as they can be overridden%.  But in particular, if the
program has a single input and a single output (as does yacc), the
input should come from stdin and the output go to stdout, unless
overridden with command line arguments.  (Yacc has reason to want
its input to come from a file, so that it can pass information to
the C compiler in case the C code in the parser is incorrect.  But
it really should be used as `yacc foo.y > foo.c'.)
-----
% Make's `makefiles' are a good example: make reads [Mm]akefile, or
  the file(s) specified via -f arguments.  Typically one uses only a
  single makefile, but the tool is not crippled, merely convenient.
-----

>I have some experience with ``large complex systems'' under VMS, with
>attendant command files to set hundreds of logicals. The exercise of
>changing the files for some of the programs is fraught with error and
>frustration, because it is never obvious which programs use which files.

`Just change 'em all' :-) :-(

>>... One may not like the fact that a "named file" is used instead
>>of stdout, but many such programs exist in the real world.

>Many? On UNIX? Not in my experience.

A number of commercial systems available for Unix machines *are*
remarkably poorly thought out.  Most of the tools that come with the
system do not have this sort of trouble, but some of the ones you can
buy do.  Fortunately, they can be worked around with links or symlinks
or the like.  If the author hard codes full pathnames *and* provides no
way to override them, you may be out of luck, but this situation is
comparable to someone hard coding specific file ID numbers in a VMS
program.  Such a program should not be put aside lightly: it should be
thrown with great force.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris