ading Postscript files

[Mike Bilow]

John Chambers wrote in a message to Mike Bilow:

 JC> Well, '.' is in my search path, of course.  But  what 
 JC> relevance  does this have to the problem?

 JC> The problem is that I had two packages, let's call them "X" 
 JC> and  "Y", both  of  which  called  a  program  called "gs". 
 JC> One's "gs" is, say, /usr/bin/X/gs; the other's is
 JC> /usr/bin/Y/gs.  But neither X nor Y uses a  full  path; they
 JC> both just invoke "gs" and trust that the right one will be
 JC> run.  How will twiddling the search-path position of "." 
 JC> help here? For that matter, how will twiddling the search
 JC> path help at all? It seems that no specific value for $PATH
 JC> will make both X and Y  work correctly.

Logically, the program which calls 'gs' must be running from some directory. 
Assuming that these two programs are running out of different directories, you
need to define links named 'gs' in these two directories, each to the proper
'gs' executable.  Then, if your global search path has '.' early on, then the
appropriate link ('./gs') will always be found for each parent program.  If a
parent program and its 'gs' are actually in the same directory, then you don't
even need the link.

 JC> In the case of ghostview, the problem is made worse by the 
 JC> fact  that it pops up an error window that doesn't explain
 JC> the problem. If it had explained that it had called "gs" and
 JC> gotten unexpected behavior, then I would probably have known
 JC> how to fix the problem. But it didn't even deign to mention
 JC> "gs", and the diagnostics it  gave  were  (to  me  at least)
 JC> rather incomprehensible.

What would you have it return instead?  "Oops, sorry, the program I just
spawned was not the program I intended to spawn.  It gave me a valid return
code so I have no way of knowing that.  It's just a hunch."  This is on a par
with expecting an error message from a totally dead computer that says
"Warning!  Power plug not in wall."
 
-- Mike