I started looking into files such as:
/etc/profile
~/.bash_profile
etc.
in order to locate where environment variables were defined. Unfortunately, I couldn't locate the $PATH variable. I am using Bash.
The initial PATH environment variable is inherited from ... whatever launched the shell. For example commands like sudo, sshd, whatever creates your shall after a desktop login.
There also appears to be a PATH that is hardwired into the bash binary for cases where an initial PATH is not inherited. (Look at the output from strings /bin/bash.)
Then various shell initialization scripts get a go at setting or updating PATH. For example, on Ubuntu the PATH variable is updated by /etc/profile.d/apps-bin-path.sh ... which is run by /etc/profile.
You should not worry (or even ask) where PATH is set, since you should not be trusting a random distro to put the right directories in the right sequence.
Instead, you set the PATH you need in your shell's profile. That's it.
As a starting point, POSIX mandates that getconf PATH returns the system's default PATH. If you have a $HOME/bin and there's a /usr/local/bin, then you add them.
Here's what this looks like on my machine:
PATH="$(/usr/bin/getconf PATH)"
PATH="$PATH:/usr/sbin"
PATH="$PATH:/usr/local/bin"
PATH="$PATH:$HOME/bin"
With this setup, it's easy to adapt the sequence. Maybe you don't like the ancient vim in /usr/bin/vi? Compile it yourself and move /usr/local/bin to the front.
Related
Backup, first.
Before attempting to resolve this, people are worried about $PATH changes breaking things. Backup your path with echo $PATH > $HOME/bak/conf/path.bak and remember (don't put any raw files into the bak dir). Confirm your backup with cat $HOME/bak/conf/path.bak.
A minimal $PATH!
My desired path is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin.
This is a minimalist path that should break nothing on most default Linux installs (Backup, first).
I have a huge $PATH that is completely useless (like 120 lines of $PATH--caused by WSL [more later]). So far, I only know how to add to path and remove single directories from $PATH via seg.
Sounds like it should pop right up on search engines. I have a headache in my eye--:
how do I set $PATH to a raw string or purge it so I can append from null?.
Bonus points for anyone who can tell me how to set $PATH from the contents of a file!?
Best guess:
import sys, sys.path.insert(0, '/your/path')--!NO This did not work!
Temporary workaround:
You can move the path to a neutral file (or use whatever means you know) and replace / with / and then use sed to cut the unwanted part out:
PATH=$(echo "$PATH" | sed -e 's/:\/tons:\/of:\/unwanted:\/garbage$//')
Make sure you put everything you don't want between s/ and $//').
Where is this long $PATH coming from?
Related question: How to remove the Win10's PATH from WSL --$PATH is inherited every time you re-launch or perform some other actions such as possibly changing users or environments.
Why is this question different:
As if there isn't enough typing, S.O. has a nuisance dialog that asks me to write and explain why purging $PATH is different from removing one directory/path from $PATH.
Because a punch in the face isn't a kick in the butt.
If I'm understanding your question, you simply want to know how to set your Bash PATH to a fixed string (or erase it completely) and have it persist across restarts of the shell?
If so, then I'll start off by saying that this isn't recommended as it will break other things. If not now, then later.
But if you really want to set the PATH to a fixed value every time Bash starts ...
Short answer first:
Assuming fairly "default" startup files (where ~/.profile sources ~/.bashrc):
Edit your ~/.profile (or ~/.bash_profile in the rare case it exists) and add:
# Remove entirely
unset PATH
export -n PATH
# Optionally
export PATH=/new/pathItem1:/new/path/Item2
Adding this to the bottom of the file should override any other PATH modifications done previously. However, future application installations can make modifications below that, therefore overriding it.
In a very rare case where you have an interactive Bash session that isn't startup by a login shell, you could also make the same modifications to ~/.bashrc.
(Not necessarily required if the modification is the last thing called during startup, but) make sure that there are no other PATH adjustments in your ~/.bashrc or ~/.bash_profile.
More explanation:
Where is this long $PATH coming from?
Your path in Bash in WSL can potentially come from a few sources:
WSL's init process sets a default PATH for the starting application (shell). This is currently (in WSL 0.70.8):
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib
Since this is done before your ~/.profile runs, there's no need to worry about disabling it.
As you've pointed out, WSL automatically appends the Windows path to the Linux path so that you can launch Windows executables. This can be disabled using the method in the question you linked, but it's not necessary if you simply want to override the entire PATH. Setting the PATH in your ~/.profile comes after WSL sets it for the initial process (your shell).
Bash itself has a built-in, default path that is hardcoded into it for "fallback" in case no other path is passed in. This rarely ever takes effect. Most Linux systems are going to set the PATH through some other mechanism, meaning the fallback never gets activated. A typical Linux system will set the default PATH via /etc/environment, but this isn't used under WSL since the init mechanism mentioned above is needed instead.
If using Systemd or another init system in WSL, then Bash (and other POSIX shells) will process /etc/profile and files in /etc/profile.d when starting. These files may contain PATH modifications. Again, since these come before your ~/.profile, (re)setting the PATH to a fixed value will override any of these settings.
Finally, your ~/.profile or ~/.bash_profile (for login shells) and ~/.bashrc (for interactive shells are read. Typically, PATH modifications in these files look something like:
export PATH="/new/path/item:$PATH"
This prepends to the path, making that new item take priority over the previous items.
However, leaving out the existing :$PATH part will simply set it to a string literal.
It should be obvious, but if you do this without including the "normal" OS paths, you will be unable to call any command that isn't built in to Bash already with specifying its fully qualified path. For instance, ls will fail. Note that you can still:
$ ls
ls: command not found
$ /usr/bin/ls
# works
Also note that ~/.profile is called for login shells. It is possible, however, to tell WSL to launch Bash without reading ~/.profile:
wsl ~ -e bash --noprofile
The resulting shell will still have the default WSL path in this case.
I've written a simple experiment which consists of cpp and shell. The main thing that cpp does is execve("./test.sh", NULL, NULL);, and shell tries to output environment variables as follows:
printenv
echo "PATH: $PATH"
It's quite expected that the environment is empty since I've sent no environment variables, but I get the following output:
PWD=/home/user/code/security_playground/display_path
PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So, first of all, the environment is not empty. Thus, the first question is how the environment is populated? What are defaults and minimal environment you could possibly get and where is it defined (if defined in config, etc.)?
Second question is where did PATH emerge from. It's not printed by printenv, but it's there if I print it with echo, and test.sh is still capable of calling utilities. Brief googling gave me an idea of /etc/environment, but it's contents is different:
└─$ cat /etc/environment
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
Which, by the way, is surprisingly empty. Why?
I do realize that much of that should be somewhere in docs, but all my googling lead me to quite generic environment descriptions, so any answers or search hints are welcome.
Where default PATH environment variable is defined
It depends. On the distribution, on the shell, on the environment, on OS, on configuration files.
I have some systems at hand, I see:
ArchLinux adds to PATH in /etc/profile.
OpenSuSE has yet a different code that adds to PATH from /etc/profile
CentOS7 has has yet a different code in /etc/profile
I suspect that each distribution places files in slightly different places, they will ship with slightly different configuration.
how the environment is populated?
Bash has DEFAULT_PATH_VALUE that is used when PATH is not set. But don't look at the default value too much - package distrbutors overwrite it.
There is /etc/environment (and pam_env.conf) that are read by PAM on login. So when you login. But not when you chroot.
The is /etc/profile and ~/.profile files read by the shell. These scripts may read other files. So usually there is drop-in dir /etc/profile.d/*.
In bash there is /etc/bashrc or /etc/bash.bashrc /etc/bash.login /etc/bash.logout or similar and user configuration files ``~/.bashrcetc. In bash also/etc/bash_completion.dand all scripts in/usr/share/bash_completionare also sourced, when completion is enabled. BUT these files are for Bourne shell - there are also other shells, notablyzshandcsh`, and people use them and they have different syntax and different set of startup files.
Each of these scripts can manipulate PATH, it can reset it, append to it, do whatever it wants to it.
And there are also different set of files read on login/non-login + interactive/non-interactive shells, and these files can include each other (it's common to have .bash_profile or other files that just source .bashrc or similar).
What are defaults
The /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin looks like a good default that should be safe on any linux.
by the way, is surprisingly empty. Why?
My /etc/environment file is just empty and has only the default comment in linux-pam package. /etc/environment has a very simple syntax and is read by pam (there may be no pam on your system...). To modify shell environment, one would prefer shell files - so /etc/profile is the place to keep system modifications. Also /etc/environment has simple key=value syntax, wherea's in /etc/profile you have, well, shell. And /etc/environment is read on login by PAM - so putting PATH just there would break I think for example docker, it just runs a shell in chroot, there is login.
To quote the POSIX specification:
If PATH is unset or is set to null, the path search is implementation-defined.
One way way an implementation can behave when PATH is initially unset is to simply set it to a hardcoded value. (It could also refuse to run any external executables at all, or throw monkeys at your face; "implementation defined" means the standard takes no position on what the computer does in the circumstance at hand, so it's unwise to make any assumption about what that behavior will be).
Similarly, for PWD, with emphasis added:
The value is set by the cd utility, and by the sh utility during initialization
...so initializing this at shell startup time is explicitly mandated by the standard.
So I learned that in order to be able to execute a program from everywhere in the shell I have to put a reference file looking something like
#!/bin/bash
path/to/my/original/executable
in my bin-directory and make it executable.
On my current linux system (provided by my workplace) there are multiple bin-directories like
/usr/local/bin
/home/MyUsername/bin/
/home/otherUsername/bin/
For my work I have to alter a c++ program which is supposed to be usable for every user on the computer (hence I used /usr/local/bin/ sofar). But I realized that my changes to the original program do not come through... So my questions are:
Where could other bin-folders be, that I need to check for old executables?
How does my operating system (ubuntu 16.04) choose between executables in different bin-locations but with the same name?
Thanks in advance!
The PATH shell variable contains a colon separated list of paths to look for executables in. The list is processed left to right, the shell executes the first executable binary it finds (make sure to chmod +x the binary you are providing). If you want an easier printout you can use: echo $PATH | tr ":" "\n". Also keep in mind that a program might have been started with a different PATH than your shell and that users can customize their PATH variable. Systemwide PATH settings can usually be found in /etc/profile or /etc/profile.d/. You can use which file to display the full path expansion of file.
export TOMCAT_HOME=”$(/usr/libexec/apache-tomcat-8.0.32)”
-bash: /usr/libexec/apache-tomcat-8.0.32: No such file or directory
Can you guide me please?
The problem is the way the command is expressed:
export TOMCAT_HOME=”$(/usr/libexec/apache-tomcat-8.0.32)”
which is telling the shell to evaluate /usr/libexec/apache-tomcat-8.0.32 (and set TOMCAT_HOME to the result of that evaluation). That is probably a directory, and does not evaluate as an expression. You should do something like this:
export TOMCAT_HOME=/usr/libexec/apache-tomcat-8.0.32
which merely uses the given value /usr/libexec/apache-tomcat-8.0.32 without trying to make the value do something.
The PATH variable is a different case. You might want to add the bin-directory of Tomcat to the path, e.g., by adding
export TOMCAT_HOME=/usr/libexec/apache-tomcat-8.0.32
export PATH=$TOMCAT_HOME/bin:$PATH
at the end of your .profile file (in your home directory). When you start a (bash) shell in OSX, it initializes the PATH variable using the contents of /etc/paths. Your .profile file can add to that. (Other people may use .bashrc or .bash_profile, but you should read the manual page for bash to understand these alternatives).
I can't believe there isn't any tutorials about this after googling.
Can someone point me a direction or explain what these lines and variables mean in .profile on mac? How can someone configure them?
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
# Finished adapting your PATH environment variable for use with MacPorts.
#export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"
export PATH=$PATH:/usr/local/mysql/bin
#export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"
#export PATH=/Applications/MAMP/Library/bin:/Applications/MAMP/bin/php5/bin:/Applications/MAMP/htdocs/cake/cake/console:/opt/local/bin:/opt/local/sbin:$PATH
export PATH=/android-sdks/platform-tools:~/android-sdks/tools:$PATH
export PATH=/Users/android-sdks/platform-tools:/Users/android-sdks/tools:$PATH
Any line starting with # is a comment. PATH= sets the value of the PATH variable, $PATH expands to the current value, and the export at the beginning makes the value available to programs that you run from the terminal.
Let's assume that the initial value of PATH is /usr/bin:/bin.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
Replace $PATH with the previous value of $PATH. So the above sets PATH to
/opt/local/bin:/opt/local/sbin:/usr/bin:/bin
Moving forward,
export PATH=$PATH:/usr/local/mysql/bin
Again, replace $PATH with the previous value:
/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/local/mysql/bin
After
export PATH=/android-sdks/platform-tools:~/android-sdks/tools:$PATH
we have
/android-sdks/platform-tools:~/android-sdks/tools:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/local/mysql/bin
(The ~ is a special token that will be replaced with the path to your home directory, but you should get the picture.)
And finally, after
export PATH=/Users/android-sdks/platform-tools:/Users/android-sdks/tools:$PATH
we get
/Users/android-sdks/platform-tools:/Users/android-sdks/tools:/android-sdks/platform-tools:~/android-sdks/tools:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/local/mysql/bin
PATH is used to find commands that you enter on the command line. So if you type foo, the shell will look for the names below, in the order specified:
/Users/android-sdks/platform-tools/foo
/Users/android-sdks/tools/foo
/android-sdks/platform-tools/foo
~/android-sdks/tools/foo
/opt/local/bin/foo
/opt/local/sbin/foo
/usr/bin/foo
/bin/foo
/usr/local/mysql/bin/foo
To see the current value of PATH, run
echo $PATH
Should you add new directories to the beginning of PATH, or to the end? It doesn't always matter, but sometimes it does. It depends on which locations you want the system to check first.
You should add to the beginning if the goal is to search other directories before looking in the default ones. For example, git is a utility used to manage source code. If I wanted to install a newer version of git in ~/git and use that by default, I'd do:
export PATH=~/git/bin:$PATH
This means that ~/git/bin/git would override /opt/local/bin/git.
On the other hand I might prefer to have the administrator install git system-wide. If I want to use my local copy only until the administrator makes it available for everyone, then this makes more sense:
export PATH=$PATH:~/git/bin
In this case ~/git/bin/git would only be used if /opt/local/bin/git didn't already exist since /opt/local/bin is earlier in the path.
A lot of commands won't exist in more than one place. For example you might write my-backup-script and put it on an Apple Time Capsule at /Volumes/Capsule/scripts. It's not likely that there would be a command called my-backup-script in any other location to conflict. So either of the following commands would let you type my-backup-script and run the right script:
export PATH=/Volumes/Capsule/scripts:$PATH
or
export PATH=$PATH:/Volumes/Capsule/scripts
Is one better? My advice would be to do the latter. Remember that system will need to search the directories in $PATH, in order, for every command that it needs to find. Most commands will be on the local system, so it makes the most sense to put slower network storage at the end of the path.
From the man page, export simply sets an environment variable.
The PATH environment variable tells your Mac where to look for commands that you type on the command line, in the order that it should look. It is a list of paths, delimited by a colon.
The value $PATH is the current value of the PATH environment variable.
Thus, a line like
export PATH=/foo:$PATH
prepends /foo to the PATH
and
export PATH=$PATH:/foo
appends /foo to the PATH
Run man
And then answer the question as export
You can see the current PATH value and observe that there are more than one path present.
(mine was /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin)
Observe that : represents end of a single path.
You can retrieve this by using $PATH
Now when you want to add one more path to this list then you need to append current path to new path like /newPath:$PATH or $PATH:/newPath.
And at last for saving it you need to use export PATH=$PATH:/newPath.
Note : This answer is for novice developers.