ading Postscript files

[minya!jc at tarnhelm.blu.org (John Chambers)]

| 
|  JC> Well, '.' is in my search path, of course.  But  what 
|  JC> relevance  does this have to the problem?
| 
| 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.

As I read this, there is a fundamental misunderstanding about how  the
"current  working  directory"  concept is implemented.  If I run, say,
ghostview from  directory  /foo/bar  (i.e.,  the  "pwd"  command  says
"/foo/bar"),  then  that  is  where  ghostview  is  running.  If it is
installed in, say, /usr/bin, this has no relevance  whatsoever  as  to
where  it  is  running.  it is running in my current directory.  If it
calls, say, "gs", the gs that runs is the first one  found  in  $PATH,
and where its parent is installed is totally irrelevant.

Your solution would require installing copies of (or links to) gs  and
ghostview  in  every one of my abc directories.  This isn't practical,
especially if I don't have a clue as to what ghostview expects to find
there.

(In fact, one of the FAQs in Unix newsgroups  is  how  a  program  can
learn  its  full name, i.e., what directory its object file resides in
and what its object file's name is.  The short answer is  "It  can't."
There  is  no reliable way for a program to discover its own full path
name, or its parent's for that matter.  It doesn't matter  how  useful
this  information  would  be;  a  "standard"  Unix -or POSIX or linx -
system will tell a process what directory it's  running  it,  but  not
where its object file resides.)

|  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."

What I would have it return is some error message along the  lines  of
"I  tried running the command `gs foo.ps` and it gave me the following
error ...".  Leaving out the name of the program that failed is  *not*
equivalent to saying "Warning! Power plug not in wall." It's more like
saying "Opps! I tried something; it failed.  I'm not going to tell you
what it was.  Lots of luck figuring it out, sucker!"  

There is, of course, a long tradition in the  computer  biz  of  doing
things  this  way,  and  ghostview's  refusal to name the program that
failed is well within that tradition. It is one of the reasons that so
much  software  has  such  a  reputation  for user-hostility among the
general population.  IMHO, software that misbehaves in this way should
get  the  public  notice and ridicule that they deserve.  It would not
have been at all difficult for ghostview to name the program that  was
failing.   It  knew  the command it was trying to run, and it wouldn't
have taken much more than one more %s in the fprintf format to include
the subprogram's name.  Omitting it is inexcusable.