Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ading Postscript files



|  JC> If this hadn't been true, solving the problem would presumably 
|  JC> have involved  some  scheme to have different search paths 
|  JC> depending on which package I was using. 
| 
| Have you considered putting '.' in your search path?  There are pros
| and  cons  to  this,  but one of the nice things about Linux is that
| you're the sysadmin and get to make these decisions.

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

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

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




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org