Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.unix.questions Subject: Re: VMS: logicals UNIX: links, but... Message-ID: <995@quintus.UUCP> Date: 14 Apr 89 03:14:41 GMT References: <475@caldwr.UUCP> <810035@hpsemc.HP.COM> Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 107 In article <475@caldwr.UUCP> rfinch@caldwr.UUCP (Ralph Finch) asks: > [How to simulate VMS "Logical Names"] chris@mimsy.UUCP (Chris Torek) replies: > [redirection, symlinks, logical variables] In article <810035@hpsemc.HP.COM> gph@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?"