Environment variables

neutron has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Environment variables by doom (Deacon) on Feb 09, 2009 at 01:24 UTC
Environment Variables are an old unix feature to let users customize their environment in different ways. Essentially they're a shell feature for sharing information between applications. For example, there's an EDITOR environment variable that you can set to "emacs" or "vi" (or "pico" or whatever), and any app that wants to give you the ability to edit some text is supposed to check EDITOR to find out which editor to kick you into. In the example you quoted, the idea is instead of having a $VERBOSE global inside of your perl code, you've got an even more global VERBOSE environment variable so that different processes can see if you're in a chatty mood or not. The "//" is a newish perl feature, it's a variant of "\|\|". The idea is that the code looks for the VERBOSE environment variable to get the $Verbose setting, but if it can't find that envar, it'll default to 1 instead. "//" is defined-or, so it checks to see if it's defined, rather than checking to see that it's true, so that a setting of "0" will be passed through.	[reply]
Re: Environment variables by kennethk (Abbot) on Feb 09, 2009 at 01:32 UTC
It's probably worth while to point out Windows has environmental variables as well, although, as with all things M$ they try to protect the user from them. To see what's set on your system (under XP), select properties on "My Computer", click the advanced tab, and click on the "Environment Variables" button near the bottom.	[reply]
Re^2: Environment variables by GrandFather (Saint) on Feb 09, 2009 at 02:05 UTC
or enter `set` in a cmd window. Perl's payment curve coincides with its learning curve.	[reply] [d/l]
Re: Environment variables by Anonymous Monk on Feb 09, 2009 at 01:22 UTC
I think you're supposed to read the chapter :) http://en.wikipedia.org/wiki/Environment_variable perlop	[reply]
Re: Environment variables by locked_user sundialsvc4 (Abbot) on Feb 09, 2009 at 06:16 UTC
Here's a good (and typical...) example. Let's say that I'm setting up a new web-site for a new client. I'll have a “deployed” copy of the site, which talks to the “real” databases, and I'll have a second “dev” copy (identical to the first...) which talks to the development databases. Did you catch that? “Identical to” the first? Environment-variables are a great way, and a very simple way, to (say...) tell the software that it's running in “production,” or “dev.” You simply arrange (by whatever means may be appropriate...) for the appropriate value to be stored, and the app can see it in the "`$ENV{}`" hash. Easy! As others have mentioned, this concept has been around for a very long time now, and both Windows and Linux and Unix all implement it. An environment-variable is nothing more than “a named string,” and every process in the system can have its own (moderately-sized...) list of them. So it's both useful and easy-to-implement.
Re: Environment variables by CountZero (Bishop) on Feb 09, 2009 at 05:52 UTC
Another way of seeing it is as a primitive precursor of the Windows registry; or the registry as an over-developed descendant of the environment. Of course Windows cannot settle on one of them and uses both, ... plus individual configuration files (`.cfg` or `.ini`) placed left and right on your hard disk. Fortunately, Perl knows how to deal with all of them! CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply] [d/l] [select]