<commit_before>[[about_environment_variables]]
== Appendix D: About environment variables

The Phusion Passenger compilation process can be customized with environment variables.

Environment variables are named values that affect how the system works. For example they tell the system where to look for commands (the `PATH` variable) or where to look for libraries (`LD_LIBRARY_PATH`). Their names are often in all-uppercase. Sometimes people refer to an environment variable with a dollar sign `$` in front, but that's the same thing: when people say "the $PATH environment variable" they mean "the PATH environment variable". This is because the dollar sign `$` is a shell syntax for refering to an environment variable, as you will learn later.

Environment variables are set on a **per-process** basis, but they are **inherited** by child processes. This means that if you set environment variables in process A, another already running process B will not see these new environment variables. But if A spawns a child process C, then C will have all environment variables that A had. If you once again change the environment variables in A, then C will not see the changes.

The per-process nature of environment variables some implications. When you set environment variables in your `bashrc` or other bash startup files...

 * ...only newly spawned bash shells see them.
 * ...the web server usually does not see them, because the web server tends to be started from init scripts, not from bash.
 * ...cron jobs do not see them, because cron jobs' environment variables are entirely dictated by their crontabs.

NOTE: Because this chapter is meant for beginners, it assumes that the reader uses the bash shell. This chapter does not describe instructions for zsh, csh or other shells. We assume that users of other shells are familiar with the Bourne shell syntax, and know how to apply the instructions in this chapter in their shells' native syntaxes.

=== Working with environment variables

You can see all environment variables in your shell by running the following command:

[source,sh]
---------------------------------
env
---------------------------------

You can set an evironment variable with the syntax `export <NAME>=<VALUE>`. For example, to set the `APXS2` variable to the value `/usr/sbin/apxs2`:

[source,sh]
---------------------------------
export APXS2=/usr/sbin/apxs2
---------------------------------

Any process that you run from your shell from that point on will have said environment variable:

[source,sh]
---------------------------------
export APXS2=/usr/sbin/apxs2
ruby -e 'p ENV["APXS2"]'
# => "/usr/sbin/apxs2"
---------------------------------

.The "export" keyword is important
[NOTE]
===================================================
You **must** set the `export` keyword. If you omit the `export` keyword then the environment variable will not be visible to other processes:

[source,sh]
---------------------------------
APXS2=/usr/sbin/apxs2
ruby -e 'p ENV["APXS2"]'
# => nil
---------------------------------
===================================================

You can reference an environment variable in your shell by typing the `$` sign followed by the environment variable's name. For example, to see the value of the `PATH` variable:

[source,sh]
---------------------------------
echo $PATH
---------------------------------

You can also use this trick to extend the value of an environment variable:

[source,sh]
---------------------------------
export PATH=/usr/bin

# Prepends '/opt/local/bin', so that it becomes /opt/local/bin:/usr/bin
export PATH=/opt/local/bin:$PATH
# Appends '/usr/local/bin', so that it becomes /opt/local/bin:/usr/bin:/usr/local/bin
export PATH=$PATH:/usr/local/bin
---------------------------------

=== The PATH environment variable

The `PATH` environment variable dictates where the system looks for command. It is a comma-separated list of directories. If you get a "command not found" error while you know that the command is installed, then setting `PATH` will help. For example suppose that the command `frobnicator` is in `/opt/local/bin`:

[source,sh]
----------------------
user@localhost bash$ frobnicator
bash: frobnicator: command not found
----------------------

We verify that `/opt/local/bin` is not in `PATH`:

[source,sh]
----------------------
user@localhost bash$ echo $PATH
/bin:/usr/bin:/usr/local/bin
----------------------

We can run `frobnicator` through it's full path...

[source,sh]
----------------------
user@localhost bash$ /opt/local/bin/frobnicator
# => success!
----------------------

...or we can add `/opt/local/bin` to `PATH`.

[source,sh]
----------------------
user@localhost bash$ export PATH=$PATH:/opt/local/bin<commit_msg>PATH is colon-separated, not comma-spearated.<commit_after>[[about_environment_variables]]
== Appendix D: About environment variables

The Phusion Passenger compilation process can be customized with environment variables.

Environment variables are named values that affect how the system works. For example they tell the system where to look for commands (the `PATH` variable) or where to look for libraries (`LD_LIBRARY_PATH`). Their names are often in all-uppercase. Sometimes people refer to an environment variable with a dollar sign `$` in front, but that's the same thing: when people say "the $PATH environment variable" they mean "the PATH environment variable". This is because the dollar sign `$` is a shell syntax for refering to an environment variable, as you will learn later.

Environment variables are set on a **per-process** basis, but they are **inherited** by child processes. This means that if you set environment variables in process A, another already running process B will not see these new environment variables. But if A spawns a child process C, then C will have all environment variables that A had. If you once again change the environment variables in A, then C will not see the changes.

The per-process nature of environment variables some implications. When you set environment variables in your `bashrc` or other bash startup files...

 * ...only newly spawned bash shells see them.
 * ...the web server usually does not see them, because the web server tends to be started from init scripts, not from bash.
 * ...cron jobs do not see them, because cron jobs' environment variables are entirely dictated by their crontabs.

NOTE: Because this chapter is meant for beginners, it assumes that the reader uses the bash shell. This chapter does not describe instructions for zsh, csh or other shells. We assume that users of other shells are familiar with the Bourne shell syntax, and know how to apply the instructions in this chapter in their shells' native syntaxes.

=== Working with environment variables

You can see all environment variables in your shell by running the following command:

[source,sh]
---------------------------------
env
---------------------------------

You can set an evironment variable with the syntax `export <NAME>=<VALUE>`. For example, to set the `APXS2` variable to the value `/usr/sbin/apxs2`:

[source,sh]
---------------------------------
export APXS2=/usr/sbin/apxs2
---------------------------------

Any process that you run from your shell from that point on will have said environment variable:

[source,sh]
---------------------------------
export APXS2=/usr/sbin/apxs2
ruby -e 'p ENV["APXS2"]'
# => "/usr/sbin/apxs2"
---------------------------------

.The "export" keyword is important
[NOTE]
===================================================
You **must** set the `export` keyword. If you omit the `export` keyword then the environment variable will not be visible to other processes:

[source,sh]
---------------------------------
APXS2=/usr/sbin/apxs2
ruby -e 'p ENV["APXS2"]'
# => nil
---------------------------------
===================================================

You can reference an environment variable in your shell by typing the `$` sign followed by the environment variable's name. For example, to see the value of the `PATH` variable:

[source,sh]
---------------------------------
echo $PATH
---------------------------------

You can also use this trick to extend the value of an environment variable:

[source,sh]
---------------------------------
export PATH=/usr/bin

# Prepends '/opt/local/bin', so that it becomes /opt/local/bin:/usr/bin
export PATH=/opt/local/bin:$PATH
# Appends '/usr/local/bin', so that it becomes /opt/local/bin:/usr/bin:/usr/local/bin
export PATH=$PATH:/usr/local/bin
---------------------------------

=== The PATH environment variable

The `PATH` environment variable dictates where the system looks for command. It is a colon-separated list of directories. If you get a "command not found" error while you know that the command is installed, then setting `PATH` will help. For example suppose that the command `frobnicator` is in `/opt/local/bin`:

[source,sh]
----------------------
user@localhost bash$ frobnicator
bash: frobnicator: command not found
----------------------

We verify that `/opt/local/bin` is not in `PATH`:

[source,sh]
----------------------
user@localhost bash$ echo $PATH
/bin:/usr/bin:/usr/local/bin
----------------------

We can run `frobnicator` through it's full path...

[source,sh]
----------------------
user@localhost bash$ /opt/local/bin/frobnicator
# => success!
----------------------

...or we can add `/opt/local/bin` to `PATH`.

[source,sh]
----------------------
user@localhost bash$ export PATH=$PATH:/opt/local/bin
{'fraction_non_alphanumeric': 0.20632593213238373, 'fraction_numerical': 0.002304147465437788, 'mean_word_length': 2.6307984790874523, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '929113', 'n_tokens_mistral': 2401, 'n_tokens_neox': 2271, 'n_words': 1161}