VMS: logicals UNIX: links, but...

[Richard A. O'Keefe]

In article <475 at caldwr.UUCP> rfinch at caldwr.UUCP (Ralph Finch) asks:
> [How to simulate VMS "Logical Names"]
chris at mimsy.UUCP (Chris Torek) replies:
> [redirection, symlinks, logical variables]
In article <810035 at hpsemc.HP.COM> gph at hpsemc.HP.COM (Paul Houtz) says:
> [That's not good enough.]

Houtz's basic point is that there are lots of programs with hardwired
file names in them, and that there is a practical need for something
much more like logical names than Torek's recommended substitutes.

I take leave to doubt this.  It has always been good style in UNIX
for programs to read from standard input and write to standard output,
and to take other file names either from the command line, from an
environment variable, or from a data set.  Anyone who or any company
that offers for sale to be used under UNIX which uses hard-wired
file names for the user's input and output data sets is so incompetent
(or so contemptuous of the UNIX environment) that you would be foolish
to trust any other aspect of the program.

Houtz says:
>I have had to change the SOURCE CODE of programs in order to get them
>to open different files.   This is really >a pain. 

Yes it is.  But it isn't UNIX's fault.  It's the fault of a programmer
who couldn't give a damn about his customers.  UNIX provides all the
tools you need to write programs which do not have this problem.

Chris Torek showed how to use environment variables in the C shell.
In the Bourne shell it is even easier:
 % master=db.mst update=todays.upd log=error.log my-db-update-prog

Another common practice for UNIX programs is to have a command line
argument (or environment variable) which specifies one or more
directories where relative file names are to be looked for.

I would like to point out that there are severe conceptual problems
with VMS logical names.  Amongst other things, there can be file
names X, Y such that X translates to Y (and translation terminates
at that point), while Y translates to X (and translation terminates
at that point).

There is no difficulty in running any number of instances of a
well-written general ledger program under UNIX.  Why buy a bad one?

We have a library package which lets a program apply variable and
tilde expansion to a file name if the programmer so chooses.  It was
easy to write.  (About 80 lines of C, excluding comments.)  We have
another package which lets you search through a list of directories
for a file (like logical names with multiple alternatives).

If a program contains hard-wired file names, then you have to know
what those file names are in order to use it.  Suppose for argument's
sake that they are called tom, dick, and harry.

	#!/bin/sh
	# shoddy RealTom RealDick RealHarry
	# invokes the really-shoddy program with files tom, dick,
	# and harry associated with $RealTom, $RealDick, $RealHarry.
	# You can pass the real file names as arguments; if they are
	# omitted they will be taken from the environment variables
	# of the same name.
	case $# in
	  0) ;;				# use $tom, $dick, $harry
	  1) tom=$1 ;;			# use $1,   $dick, $harry
	  2) tom=$1 dick=$2 ;;		# use $1,   $2,    $harry
	  3) tom=$1 dick=$2 harry=$3 ;;	# use $1,   $2,    $3
	  *) echo "Usage: shoddy tom dick harry" >&2 ; exit 1 ;;
	esac
	here=`pwd`			# current directory
	case ${tom:?} in		# error if tom is unbound
	  /*) t=$tom ;;			# tom is already absolute
	  *)  t=$here/$tom ;;		# prepend current directory
	esac				# t is absolute version of tom
	case ${dick:?} in		# error if dick is unbound
	  /*) d=$dick ;;		# dick is already absolute
	  *)  d=$here/$dick ;;		# prepend current directory
	esac				# d is absolute version of dick
	case ${harry:?} in		# error if harry is unbound
	  /*) h=$harry ;;		# harry is already absolute
	  *)  h=$here/$harry ;;		# prepend current directory
	esac				# h is absolute version of harry
	WorkingDir=/usr/tmp/shoddy$$	# $$ identifies this process
	mkdir $WorkingDir
	chdir $WorkingDir
	ln -s $t tom			# ./tom points to $tom
	ln -s $d dick			# ./dick points to $dick
	ln -s $h harry			# ./harry points to $harry
	really-shoddy			# run the really shoddy program
	s=$?				# save its status code
	rm tom dick harry		# clean up files
	cd $here			# just to be at a definite place
	rmdir $WorkingDir		# clean up directory
	exit $s

It's possible to simplify this:  I have a tool 'sl' which converts
its file name argument to absolute file and then does a symbolic link,
so I could just do
	sl ${dick:?} $WorkingDir/dick
instead of using the case statements above.  The 'trap' construct
should be used to make sure that the cleanup happens.  And so on.
If the program uses relative file names as well as hard-wired file
names, you're still in trouble, but you're likely to be in worse
trouble if you _do_ succeed in running the program!

What was that about "it is better to light a single candle than to
curse the darkness?"