when checking my $PATH on ubuntu (16.04)
I get a long list of directories, few of which even do not exist in my file
system, and some of them I just don't need:
echo $PATH
.../usr/games:/usr/local/games:/snap/bin
where they are created and how can I remove them?
I wnant to control the creation of the $PATH, rather than
correct it later by the tricks described in
https://unix.stackexchange.com/questions/108873/removing-a-directory-from-path
Some typical places where $PATH can be set when starting up a bash shell on Ubuntu include:
/etc/profile
~/.profile
~/.bashrc
where ~ represents your home directory.
Also look at any scripts called by those scripts.
There may be other things that get called when starting up a bash shell, depending on various conditions. For details, take a look at the INVOCATION section from the command:
$ man bash
See this answer from askubuntu.com to edit the path either using a text editor or the command line.
I found the answer to your question today. The path you want to edit is in /etc/environment.
My setup is zsh 5.0.5 in arch linux
I have set the PATH variable as below in .zshenv
typeset -U path
path=(~/bin $path)
DW=$HOME/Downloads
but it didn't work. print $PATH shows only
/usr/local/bin:/usr/bin:/usr/bin/vendor_perl:/usr/bin/core_perl
.zshenv was read, because I could see DW variable is set. Only PATH variable isn't set. And what I don't understand is, after rename the .zshenv to .zshrc, PATH variable just works as intended.
Need any special treatment setting environment variables in .zshenv?
I just encountered this problem myself, and the real answer is that Zsh on Arch sources /etc/profile – which overwrites and exports PATH – after having sourced ~/.zshenv.
See: https://wiki.archlinux.org/index.php/Zsh#Configuration_files
It seems that when you have macos or some linux distros there is a canonical solution to the problem which involves /etc/paths or /etc/paths.d. You should be letting /usr/libexec/path_helper construct your path for you using configuration files.
This immediately solved the problem in all places for me.
I've got the same problem. The cause was my .zshrc (fresh install of oh-my-zsh) override PATH (ignoring existing value):
export PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl"
To fix, I comment the line.
I'm getting the following error when running "brew doctor":
Error: Your Cellar and TEMP directories are on different volumes.
OS X won't move relative symlinks across volumes unless the target file already
exists. Brews known to be affected by this are Git and Narwhal.
You should set the "HOMEBREW_TEMP" environmental variable to a suitable
directory on the same volume as your Cellar
How do I set this variable? And what should I set it to? I can't seem to find anything about this when googling.
You set your HOMEBREW_TEMP by editing your ~/.bash_profile and doing this:
export HOMEBREW_TEMP=/new/path
Then start a new shell.
Alternatively type that into any already open shell.
Google setting shell environment variables for further information.
I fixed this problem by setting the path of the temp folder manualy.
First i created a folder temp in /usr/local/ and then added the following to my zsh file nano ~/.zshrc
export HOMEBREW_TEMP=/usr/local/temp
Same problem occurred to me. I actually have configured separate disk in memory for /private/tmp. Hope that's why this error occurred.
To solve this issue, create a directory somewhere, like /usr/local/brew_temp
Then add following line to file ~/.profile. If file doesn't exist create that file
export HOMEBREW_TEMP=/usr/local/brew_temp
In each restart it will set the HOMEBREW_TEMP environment variable to that path. After setting these option either you can restart OS X or run following in command line if you don't want to restart
. ~/.profile
For anyone that runs into this in the future, try restarting your computer and then running brew doctor again. That fixed it for me.
I was trying to set up a system similar to heroku where I would store secret keys in environmental variables and then access them from my rails app like this:
secret = ENV['EMAIL_PASSWORD']
I know heroku lets you do heroku config:add EMAIL_PASSWORD=secret, and I wanted to do something like that for my own ubuntu box running nginx and Passenger.
Should I add these variables as exports in .bashrc or .bash_login so that on system reboot these variables are automatically set?
I'm not sure when each of those files gets read in.
You can use dotenv gem which loads the .env file as environmental variables. You can generate the .env file for different environments, and need not be rather should not checked into your repository.
Keep in mind that nginx may not be running under the same environment as you are, and usually (pronounced "Apache") we add env-vars in the server config file via SetEnv. However, nginx doesn't have such a feature... nor does it need one, I believe.
sudo -E /usr/local/sbin/nginx
When running nginx for it to be aware of your own user env vars.
Or, check out the env command (see here):
env EMAIL_PASSWORD=secret
To answer your question, yes, you should use export statements in your shell config files.
This is documented in nginx. It removes all environment variables except TZ when running the workers. If you want to add an environment variable, add the following to the top of the nginx configuration:
# The top of the configuration usually has things like:
user user-name;
pid pid-file-name;
# Add to this:
env VAR1=value1;
env VAR2=value2;
# OR simply add:
env VAR1;
# To inherit the VAR1 from whatever you set in bash
The normal export or anything you do in bash has no guarantee of getting passed on to nginx, due to the way the init scripts are written (we don't know if they're using sudo with a clean environment, etc). So I'd rather put these in the nginx configuration file itself, rather than depending on the shell to do it.
Edit: Fix link
(this is probably a overkill, but maybe it'll be useful)
Some things to keep in mind:
Environment variables are somewhat public, and can be seen by other processes as easily as added an option to the ps(1) command (like ps e $$ in bash) or looking at /proc/*/environ, though both are restricted at least to the same user (or root) on modern systems. Don't rely on them being secret if you have another fairly easy option available.
~/.bashrc is the wrong place for environment variables, since they can be computed once at login in ~/.bash_login, ~/.bash_profile, or ~/.profile, depending on your usage, and passed down to all descendent shells. In contrast, ~/.bashrc actions tend to be recomputed on every shell invocation (unless explicitly disabled).
Putting bash code in the ~/.profile can confuse other sh-descendent shells and non-shell tools which try to read that file, so having the bash-specific ~/.bash_login or -_profile contain the bash-specific things, and using . ~/.profile for the more general things (LESS, EDITOR, VISUAL, LC_COLLATE, LS_COLORS, etc), is friendlier to the other tools.
Environment variables in ~/.profile should be in the old Bourne shell form (VAR=value ; export VAR). On Linux, this isn't usually critical, though on other Unixen this can be a big issue when an older version of "sh" tries to read them.
Some X sessions will only read ~/.profile, not ~/.bash_login or the others mentioned above. Some will look for a ~/.xsession file will need to be modified to have . $HOME/.profile if it doesn't already somehow.
System-wide settings would be put instead in something like /etc/profile.d/similar-to-heroku.sh. Note that the ".sh" is only present since the file will be used with "." or "source" - shell scripts should never have command-name extensions in any form of Unix/Linux.
Most environment variables get ditched when one sudos to root, as ybakos points out. Similar issues show up in crontabs, at jobs, etc. When in doubt, adding env | sort > /tmp/envvars or the like a suspect script can really help in debugging.
Be aware some distributions have shell startup scripts so contorted they end up actually defying the order given in the bash(1) manual page. Anytime you find a default user ~/.profile checking for $BASH or $BASH_VERSION, you may be in one of these, um..., "interesting" environments, and may have to read through them to figure out where the control flow goes (they should be using a bash-specific ~/.bash_profile or ~/.bash_login, which includes the more generic ~/.profile by reference, thus letting the bash executable do the work instead of having to write $BASH checks in shell code).
~/.bash_profile (or ~/.bash_login) can certainly include . ~/.bashrc, but the environment variables belong in the ~/.bash_profile (if bash-specific) or the ~/.profile included from it (if you're using this mechanism and have envvars for everything else in there) as DeWitt says, just remember to put the . ~/.bashrc AFTER the .bash_profile's . ~/.profile and other environment variables, so that both login and all other invocations of the ~/.bashrc can rely on the envvars already being set. An Example ~/.bash_profile:
# .bash_profile
[ -r ~/.profile ] && . ~/.profile # envvars
[ -r ~/.bashrc ] && . ~/.bashrc # functions, per-tty settings, etc.
#---eof
The [ -r ... ] && ... works in any Bourne shell descendent and doesn't cause errors/aborts if the .profile is missing (I personally have a ~/.profile.d/*.sh setup as well, but this is left as an entirely optional exercise).
Note that bash only reads the first file of these three which it finds:
~/.bash_profile
~/.bash_login
~/.profile
...so once you have that one, the use of the other two is entirely under control of the user, from bash's perspective.
I put them in my nginx config, specifically in the server definition for the app using the passenger_env_var command:
server {
server_name www.foo.com;
root /webapps/foo/public;
passenger_enabled on;
passenger_env_var DATABASE_USERNAME foo_db;
passenger_env_var DATABASE_PASSWORD secret;
passenger_env_var SECRET_KEY_BASE the_secret_keybase;
}
This works for me. See the phusion passenger docs for more info.
I have a script in /usr/local/bin folder that sets some env vars and then executes Ruby. I define the path to Ruby in my (Apache, not Nginx) conf file to that file in /usr/local/bin.
example:
#!/bin/sh
# setup env vars here
export FOO=bar
export PATH_TO_FOO=/bar/bin
export PATH=$PATH:PATH_TO_FOO
# and execute Ruby with any arguments passed to this script
exec "/usr/bin/ruby" "$#"
You should read this response to another question, it will help:
https://stackoverflow.com/a/11765775/1217298
EDITED :
Ok sorry i read it too fast, you can check how to save your ENV variables here :
https://help.ubuntu.com/community/EnvironmentVariables
http://www.cyberciti.biz/faq/set-environment-variable-linux/
If you use Nginx as server on your local computer, you can define your env variable into your nginx config file.
location / {
...
fastcgi_param EMAIL_PASSWORD secret; #EMAIL_PASSWORD = secret
...
}
I'm using rbenv as a version manager. Good solution to store environment variables for the project was installing the rbenv-vars plugin and putting them in .rbenv-vars file.
Here is a useful post:
Deploying app ENV variables with Rbenv, Passenger and Capistrano
For those battling this that are using RVM. Make sure that your default environments file is including your user's .bashrc and .profile files
file: $rvm_path/environments/default
to find the path run this command:
ls -lah `whereis rvm`/environments/default
add these two lines before the first line in that file:
source $HOME/.bashrc
source $HOME/.profile
The best place to keep env variables for your project is /etc/profile.d/YOUR_FILE.sh,
Here you can find the documentation which explains in details where to keep env variables for different scenarios.
In case anyone had the same type of question as I did, here's a nice little writeup about the different .bash* files: http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html
In summary:
For the most part:
.bash_profile is read when you log into the computer and .bashrc is read when you start a new terminal. For Mac OSX .bash_profile is read with every terminal window you start.
So, the recommended procedure is to source .bashrc from .bash_profile so all the variables are set when you login to the computer. Just add this to .bash_profile:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
You have to add the export lines into your .profile file under your home folder...
Environment variables are being set on login...
I want add some directory to the $PATH when running sudo, this is a (semi) permanent requirement, not something that needs to be added to the scripts themselves. I notice that Django has managed to do it, (my $PATH when running sudo is "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/django/django-trunk/django/bin") - so how did it do that?
This is the line in the sudoers file that resets:
Defaults env_reset
You can work around this by adding PATH to env_keeps or by adding this line:
Defaults env_keep = "PATH"
EDIT: meder, you do not disable env_reset, you simply bypass the path reset
Or you can remove the offending env_reset line.
Even better though, you can declare a secure_path that will replace PATH when sudo is run:
Defaults secure_path="/bin:/usr/bin"
That way you can control what specific directories to include in the path.
I think this should work out if you save it in /root/.bashrc:
export PATH=/www/foo:$PATH
I forget if it's PATH or PYTHONPATH and if it actually matters, this is based on my user's .bashrc:
export PYTHONPATH=/www/django:$PYTHONPATH
You can set the variable in /etc/environment, and then use "sudo -i" to run the script (works in ubuntu 10.10).