[gs-bugs] [Bug 690229] HEAD still tries to open some Resource files

[b***@ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=690229

--- Comment #4 from Jason Giglio <***@gigstaggart.com> 2010-03-18 18:24:09 UTC ---
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.

[b***@ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=690229

***@yahoo.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@yaho
| |o.com

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=690229

Ken Sharp <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@nurealm.net

--- Comment #5 from Ken Sharp <***@artifex.com> ---
*** Bug 698709 has been marked as a duplicate of this bug. ***

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=690229

--- Comment #6 from James <***@nurealm.net> ---

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...

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=690229

Chris Liddell (chrisl) <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@artifex.com

--- Comment #7 from Chris Liddell (chrisl) <***@artifex.com> ---
(In reply to James from comment #6)

Post by b***@artifex.com
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?

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=690229

Post by b***@artifex.com
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.