note that this is strace output. It also tries to load a number of library
postscript files from the current directory. Perhaps some of the file or
resource enumeration logic isn't terminating properly.

Test command line:

$ strace debugobj/gs -q -dBATCH 2>&1 | grep open

Confirmed this still exists in recent SVN.

More precisely, Ghostscript is searching for the following file names:

open("gs_init.ps", O_RDONLY)            = -1 ENOENT (No such file or directory)
open("/home/alexcher/gs_svn/gs/Resource/Init/ProcSet/CIDInit", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/home/alexcher/gs_svn/gs/Resource/ProcSet/CIDInit", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/home/alexcher/gs_svn/gs/Resource/Init/Encoding",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/alexcher/gs_svn/gs/Resource/Encoding",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/alexcher/gs_svn/gs/Resource/Encoding",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/alexcher/gs_svn/gs/Resource/Init/Encoding/Wingdings", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/home/alexcher/gs_svn/gs/Resource/Encoding/Wingdings", O_RDONLY) = 3
open("/home/alexcher/gs_svn/gs/Resource/Init/Encoding/Wingdings", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/home/alexcher/gs_svn/gs/Resource/Encoding/Wingdings", O_RDONLY) = 3
open("/home/alexcher/gs_svn/gs/Resource/Init/Fontmap", O_RDONLY) = 3
open("/home/alexcher/gs_svn/gs/Resource/Fontmap", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/home/alexcher/gs_svn/gs/Resource/Fontmap", O_RDONLY) = -1 ENOENT (No such
file or directory)

The search on disk can be prevented by the compile tome option:
make GS_LIB_DEFAULT=

An the search in the current directory can be prevented by the run-time option:
bin/gs -P-

There's one strange line that causes gs_init.ps to be searched in the
current directory even with -P- . This can be considered as a security
hole.

lib_file_open( ...  char *fname, ... ) {
  // i_ctx_p is NULL initially
  bool starting_arg_file = (i_ctx_p == NULL) ? true : ... ;  // why ?

  if (gp_file_name_is_absolute(fname, flen)) {
    // snip
  } else {
    search_with_no_combine = starting_arg_file;  // causes search in ./
    search_with_combine = true;
  }
  // snip
}

Alex, does it search for gs_init in the current directory regardless of whether SEARCH_HERE_FIRST is set?

# Define whether or not searching for initialization files should always
# look in the current directory first.  This leads to well-known security
# and confusion problems, but users insist on it.
# NOTE: this also affects searching for files named on the command line:
# see the "File searching" section of Use.htm for full details.
# Because of this, setting SEARCH_HERE_FIRST to 0 is not recommended.

SEARCH_HERE_FIRST=1


Considering the headache this option caused me when a rogue copy of an obsolete init file was in my current working directory, I'd be in favor of killing this with fire, if possible.

*** Bug 698709 has been marked as a duplicate of this bug. ***

https://bugs.ghostscript.com/page.cgi?id=fields.html#bug_status

'Users who have the "canconfirm" permission set may confirm this bug, changing its state to CONFIRMED.'

Hmm - (2017-2009) = 8 years - hmm...

(In reply to James from comment #6)
> https://bugs.ghostscript.com/page.cgi?id=fields.html#bug_status
> 
> 'Users who have the "canconfirm" permission set may confirm this bug,
> changing its state to CONFIRMED.'
> 
> Hmm - (2017-2009) = 8 years - hmm...

Well, TBH, it is working as intended. It is not unusual for a application to have default search paths it checks for it's initialisation (and the like) files.

What makes you think this is a problem?

> What makes you think this is a problem?

This is awkward - I don't mean to be rhetorical - did you read Bug 698709?

1) The hard-coded file names for which gs is searching are not installed, and so will not, and  cannot, be found.

2) The hard-coded Path variable used by gs to search for those files would not allow those files to be found, even if the source-code directory containing those files *was* installed.

3) As far as I know, even *if* those files were found, they are not needed and are not used for any purpose.

4) I am assuming that a basic principle of "good programming" is an aspect of "efficiency", which would imply NOT wasting computing resources by performing useless "do nothing" processes, searching for files that will never be found and which would never be used, even if they were found.

If you disagree with any of those points, please address them specifically.  I am too naive about the ghostscript internals to know that you might simply be speaking in generalities, or might only be teasing me.

Ghostscript documents where it searches for things and WHY.

Note that -P- has been the default for a while, so gs does NOT (by default)
search the current directory.

In https://www.ghostscript.com/doc/current/Use.htm#Finding_files
It points out the search order. Usually for the "required" file, "gs_init.ps"
and other required files, they will be found in %rom%Resource/Init/ which
is built into the executable by default.

It is up to the invocation of 'gs' to decide whether "-P", or the "-I___"
option is given as an option, or if the GS_LIB environment variable is
defined when gs is invoked.

As far as GS_LIB_DEFAULT, which is usually a rather lengthy list of paths
built into the executable, if these paths are not to be used, the one must
rebuild ghostscript. These paths are the default on linux/unix to cooperate
with linux distributors that package Ghostscript and want them.

As far as why we keep searching paths other than %rom%Resource/ when gs is
built with COMPILE_INITS=1, well, that also is in the docs.

In particular IdiomSet, CIDInit and Fontmap are all often "merged". Not to be
exhaustive, but as with Fontmap (excerpt from doc/Use.htm):

At startup time, Ghostscript reads in the Fontmap files in every directory on
the search path (or in the list provided with the -sFONTMAP= switch, if
present): these files are catalogs of fonts and the files that contain them.

The intention is similar for the other file sets that we want merged from
a variety of sources.

Since gs can be built and invoked without needing access to any of the paths
being objected to, I am closing this (probably should have long ago) since it
works the way we intend and as documented.

Note that we may, in cooperation with the important linux distributors, decide
to reduce the GS_LIB_DEFAULT path list in the future.