![]() |
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 |
From: mikebw at bilow.bilow.uu.ids.net (Mike Bilow) 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. Unfortunately, it isn't so. People have wanted this idea to work for years in Unix, but it can't really be done. The dot refers to the current directory of the process, not the directory from which the current executable image was loaded. In particular, if I am in my home directory (/users/worley) and run, say, mv (/bin/mv), then in the process running mv, the "." in the PATH refers to /users/worley, not /bin/mv. One would think that one could invent a new special directory name to mean "the directory in which the current executable resides" (Multics has this concept), but it can't be done, because that directory has no unambiguous definition -- the executable file can be hardlinked from several different directories, and all of the links to the file are equal. Dale -- Dale R. Worley Ariadne Internet Services Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley at ariadne.com "Internet-based electronic commerce solutions to real business problems."
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |