It seems that when GhostScript 8.51 for Windows is installed in a different place than c:\gs\gs8.51 some paths are not correctly altered. I installed GhostScript 8.51 to "C:\Program Files\gs\gs8.51\..." My PATH environment variable includes C:\Progra Files\gs\gs8.51\bin;C:\Progra Files\gs\gs8.51\lib;... as it should. But when I invoke "gswin32c -?" from the command line, I get: Search path: . ; C:\Program Files\gs\gs8.51\lib ; C:\Program Files\gs\fonts ; C:\Program Files\gs\gs8.51\Resource ; c:/gs/gs8.51/lib ; c:/gs/gs8.51/Resource ; c:/gs/fonts For more information, see c:/gs/gs8.51/doc/Use.htm. Notice the four references to "c:/gs/gs8.51" (three in the Search Path and one in the For more information). Please note that this directory does not exist and does not appear in my PATH environment variable. I believe that it may be hard-coded instead of being set at install time. - Rich
unix version behaves similiarly - "gs -h" shows . : <runtime-determined locations> : <compiled-time-determined locations> for more information see <compiled-time-determined location>. FWIW, ghostscript uses GS_lIB and friends to determine the 'runtime-determined locations, not PATH.
The search path is made up from a number of components: -I command line option GS_LIB environment variable hard coded path. The Windows Ghostscript installer sets a named registry value GS_LIB to point at the installed location, which gets picked up by the GS_LIB environment variable logic. The search path you reported is normal. The hard coded path should not cause any problems.
Thank you. Well, actually it does cause a minor problem, in that it causes the help command to give misleading information. C:\>gswin32c -h ... For more information, see c:/gs/gs8.51/doc/Use.htm. That file simply does not exist. The correct place to look for more information (in my installation) is C:\Program Files\gs\gs8.51\doc\Use.htm. - Rich
Thank you, Russell for your clarification (which, IIRC, is covered in the documentation). Perhaps the concept of 'search paths' is not understood by the reporter -- the various paths are searched for the required file until the first match is found (this is drummed into unix users). Thus paths that don't exist or do not contain the requested file are irrelevant.
I do understand the concept of search paths, and I understand that including non-existent directories in a search path is harmless (except for perhaps adding a few microseconds to search the path). It is just aesthetically displeasing. Nevertheless, when a user invokes the help command, I think that it is inappropriate to instruct him to look for documentation in a directory that never existed on his system, and to expect that he will remember to substitute the real name of the directory in which he installed the software. In my opinion, it would be preferable to echo the user's actual installation directory, or if this is not possible then just give the filename with no directory. True, none of this is a critical bug -- a few microseconds here, a little inconvenience there, it doesn't really crash. Please excuse me if my suggestions seem like a waste of time, but I thought I might help to make the next version just a little cleaner. - Rich
Unfortunately, to determine which path is 'active' for the installation involves doing the search for a known file, such as gs_init.ps, then checking for the existence of the "doc" sibling to the path. This is only somewhat intricate because the implementation needs to follow the methods used in src/imainarg.c 'print_help_*' functions to only use those functions that work BEFORE the interpreter instance has been initialized, being careful to use the gp_* functions to access the filesystem and gp_file_name_combine to combine the path with the filename so that the result runs across all platforms (including VMS, Mac, as well as Windows and unix). Since GS has had this message since day one (at least since 2.5.2 when I first saw it), it is not that serious of an issue or we would have heard about before. If you wish to do this (in a cross platform manner) we will be glad to evaluate the approach and (probably) add it to the code base. We mostly close bugs that we don't intend to fix -- I closed it with WORKSFORME instead of WONTFIX. improvement to the code base (