Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!bu-cs!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.unix.questions
Subject: Re: Unix deficiencies/problems
Message-ID: <40220@think.UUCP>
Date: 6 May 89 01:32:02 GMT
References: <19472@adm.BRL.MIL> <17327@mimsy.UUCP>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 33

In article <17327@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
Describing how to use shell variables as a substitute for logical file names:
>$ joe=/home/orion/jsmith/projectA/speech
>$ splib=/home/magellan/tjones/lib/splib.a
>$ cd $joe
>$ ls $joe
>$ ar t $splib
>$ cc args -l$splib

That's fine if the file name is passed in on the command line.  But
what if a program prompts for a file name?  For instance, when
specifying files in an editor's read or write command.

On Multics, my solution to this would have been to take advantage of
dynamic linking.  All Multics programs that take file names must call
expand_pathname_ to parse a pathname into an absolute directory
pathname and a directory entry name.  It's a simple matter to place a
personalized version ahead of the standard one in one's linker search
path (in fact, I did just this, although not for the above use,
although I know people who did the above).  Now SunOS has dynamic
linking, so perhaps open(2), chdir(2), etc., could be replaced this
way; however, programs don't have to be dynamically linked, so you
would end up with a situation where logical file names are recognized
by some commands and not by others, depending only on how they were
built.  Also, this would have problems if shell wildcard expansion
returned a name that happened to match a logical name (wildcards
should generally be processed AFTER expanding logicals).

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar