Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
| 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 | |
We also thank MIT for the use of their facilities. |