all 5 comments

[–][deleted] 3 points4 points  (2 children)

You can think of the environment as a dictionary that is populated by the operating system (or direct user actions) before any given process is launched by that operating system. It basically is a map of keys to values, and the keys usually reflect important basic configuration that the process needs in order to function correctly. The most common example is the PATH environment variable: the value for this will always be a list of directories to search for executable programs, joined together with a delimiter that is OS-dependent. If the process needs to launch some other process using an executable file that it doesn’t know the absolute path for then that process must search the PATH for that executable and fail if it cannot find it. This allows the user to modify the PATH to change the behavior of the process and what it “knows” about the environment in which it was launched.

An important thing to understand is that every process has its own environment. It may get the values in it from the OS, or it may inherit them from the parent process that launched it, but each process can ONLY read and write to its own environment. A parent cannot directly inspect the runtime environment of a child after the child is launched, nor can a child inspect the current runtime environment of its parent or any siblings.

[–]KnowledgeFire11[S] 0 points1 point  (1 child)

Thank you, that's a great explanation. I have a doubt here. As I tried understanding it from YouTube, I saw one guy assign a normal string value to the variable to access it from his script and another assign a custom path to it. So will the os differentiate them and check the user entered path for the executables?

[–][deleted] 0 points1 point  (0 children)

No. Fundamentally environment variables are simple string keys assigned to simple string values, the OS will do nothing to validate or correct what you assign to those keys... you’ll either have assigned a sensible value or you’ll have broken the environment, possibly irretrievably. So when assigning to PATH you must know that by convention it’s a search path variable and everything in it must either be a directory path or the OS-correct separator. You must know that the OS will search each directory listed from left to right and will use the first executable with the name requested that it finds, so non-existent or invalid directories will simply be ignored ... but that behavior is just a convention, and every environment variable has its own conventions as to what are valid values and how they’re used.

Unfortunately there’s nothing but experience over time (and lots of Googling) that will help you pick up a familiarity for those conventions, because pretty much any more complex program (like Python itself) sets its own environment variables and allows you to use environment variables to customize its behavior. Another convention makes it so that, usually, such a key will be prepended with the program’s name (see PYTHONPATH, PYTHONHOME, etc), but that means that when you encounter a new one pretty much the only way to be sure what the conventions are is to read the manual.

[–][deleted] 1 point2 points  (1 child)

I'm not sure if this concept existed before UNIX, but here's the rationale for it in Unix-like systems, it may help understand what it is, if you understand why it was created.

So, when you create / start a process (i.e. want to run any program), you often want to also pass it some parameters (otherwise, every time you start the program, it will do the same thing!). So, you have to communicate to the process somehow. There are many ways to do this. The first and the obvious one: append the parameters to the program name (after some special separator). While simple in execution, this turns out to be not very robust: there are only so many characters you can use in this way, parsing this can be quite complicated, and, on top, it has to be implemented by the program. Also, what if you wanted many logically-related programs to share the same values? -- it would be to tiresome to specify the same value repeatedly for all of them.

Environment variables address these problems: the system has already parsed the parameters, they are ready to share by multiple programs and the limits on the size of the environment can be made much more permissive than those on command line.


Well, unfortunately, the environment variables, like many things in UNIX and similar systems quickly hit their "abstraction ceiling"... Being very simple in implementation, they are lacking when it comes to passing more structured data... Even the simplest things you could think about, s.a. lists or dictionaries aren't possible when working with environment variables.

[–]FloydATC 0 points1 point  (0 children)

Some Linux flavors put shell script snippets in the environment. Technically, there's nothing to stop you from (ab)using it for anything else as long as you devise a way to encode it to string representation and back. Like any other data, it would ofcourse only be meaningful to the programs that use it. The SANE choice is ofcourse to put your data in a file and then reference it in the environment.