8
2
if I type
echo $PATH
I only get
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
how can I add /usr/local/sbin
to the path, so it is already there the next time?
(I use debian squeeze)
8
2
if I type
echo $PATH
I only get
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
how can I add /usr/local/sbin
to the path, so it is already there the next time?
(I use debian squeeze)
11
The easiest way is to add this line to your user's ~/.bashrc
file:
export PATH=$PATH:/usr/local/sbin
Bear in mind that /sbin/
, /usr/sbin
and /usr/local/sbin
are not in normal users' $PATHs by default because these directories tend to contain "dangerous" executables. Things like fdisk
or deluser
that need administrative privileges and can harm your computer. They should be in root
's path by default and you need to be root
to run them anyway, so it migh be a good idea not to add them to a normal user's $PATH.
1
Add the following to the end of the .bashrc
of the user:
export PATH=/usr/local/sbin:$PATH
Do you recommend adding to the start (as in @criziot's answer) or end of the path (as in your answer)? Why? – drevicko – 2016-08-31T10:40:13.863
@drevicko if you add the new dir to the beginning, executables in it will take precedence. If you have two executables named
foo
, the one that was found first, so the one in the directory of your PATH that comes first, will be executed when you runfoo
. So it's up to you. If you want the new dir to take precedence, add it to the beginning, otherwise, add it to the end. – terdon – 2016-08-31T10:44:34.153@terdon doesn't really answer my question, but sbin is intended for executables that require admin preveliges and bin for those for everyone, so you'd not expect the same executable in both. That means it's probably not an issue which is first. It's usually safer to put things at the end of the path though, unless you've a good reason not to. – drevicko – 2016-08-31T11:15:27.817
@drevicko no, the only difference is precedence. For example, I like having the directory holding my own programs first, since I sometimes write wrapper scripts to replace the standard tools. – terdon – 2016-08-31T11:25:24.040
@terdon yes, but a less experienced user can get into trouble with that - if some program they run from the terminal expects certain behaviours from standard tools which are different in the folder added to the front of PATH, they may break. An example is running anaconda python (which adds itself to the front of PATH) and then using
brew
on a mac. Other examples can come from version conflicts in standard tools. – drevicko – 2016-09-01T09:29:32.040Assuming they are using bash. – vgoff – 2013-05-15T12:03:06.340
@vgoff the question is tagged with [tag:bash]. – terdon – 2013-05-15T12:05:41.493
Yes, it is. Didn't notice initially. Left it after I hit 'add comment' – vgoff – 2013-05-15T12:06:43.823
Wouldnt that add the path to $PATH again and again? And which would be the correct path to store own written bash files then? files, that the user may execute? – rubo77 – 2013-05-15T12:15:53.523
@rubo77 The PATH is only set for a shell session, and
.bashrc
is only called once at the start of the session. Your own scripts, you could store them in~/bin
, and add that to the path, for example. – slhck – 2013-05-15T12:19:12.797@rubo77 No,
PATH=$PATH:/foo
appends/foo
to the current value of$PATH
.PATH=/foo:$PATH
prepends/foo
to the current value of$PATH
. As for where you place your own scripts, the most common is~/bin
but you can use whatever you like as long as you add it to your $PATH as described. Personally I use~/scripts
. – terdon – 2013-05-15T12:20:57.133OK. but isn't there a convention where to store text-bash files that all users may execute? I created a new question about that: http://superuser.com/questions/595828/where-to-store-text-bash-files-that-all-users-may-execute-on-debian
– rubo77 – 2013-05-15T12:22:01.593@rubo77 you may be thinking of
/usr/local/bin
as/usr/bin
is generally used by the 'OS vendor'. This means that if you do updates, and your script happens to have a name of some new inclusion, it will be over-written. – vgoff – 2013-05-15T12:28:57.700