NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
--Larry Wall in <199911192358.PAA24109@kiev.wall.org>
Did I say I expect Perl to do the right thing? :-)
--Larry Wall in <199911200217.SAA24898@kiev.wall.org>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
not quite so (Score:2)
That's not what he said, read again. There are still legitimate uses for LD_LIBRARY_PATH (and its moral equivalents, not all platforms call it that). For example, Perl's build process uses that for a very good reason.
Re: (Score:2)
When I said "you" should never be using this variable, I meant the average person reading what I was writing. :) People who've done heavy hacking on Perl's build process have a high probability of running into the legitimate use cases for it, and I knew that. :)
Basically, if the developers of a package do their job right, and know what LD_LIBRARY_PATH is for and what it is not for, the end user should almost never, ever have to use it. If I purchase a huge commercial package like, say, Oracle, and have
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Re:not quite so (Score:2)
Reply to This
Parent
Re: (Score:2)
Let me also amplify that not only should a user never set LD_LIBRARY_PATH, it should never be set for him.
LD_LIBRARY_PATH is a developer-only variable. It's a test-time option, not a run-time option. Unfortunately due to many developers who don't know what they're doing, it becomes a necessary run-time option for some apps. But even then it should only be used as a method of last resort to get them running!
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers