Where should a local executable be placed?
Clash Royale CLAN TAG#URR8PPP
up vote
44
down vote
favorite
I have an executable for the perforce version control client (p4
). I can't place it in /opt/local
because I don't have root privileges. Is there a standard location where it needs to be placed under $HOME
?
Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin
?
I couldn't find such a convention mentioned on the Wikipedia article for the FHS.
Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin
directory or whatever the location of the bin
directory is?
software-installation executable directory-structure not-root-user fhs
add a comment |Â
up vote
44
down vote
favorite
I have an executable for the perforce version control client (p4
). I can't place it in /opt/local
because I don't have root privileges. Is there a standard location where it needs to be placed under $HOME
?
Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin
?
I couldn't find such a convention mentioned on the Wikipedia article for the FHS.
Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin
directory or whatever the location of the bin
directory is?
software-installation executable directory-structure not-root-user fhs
add a comment |Â
up vote
44
down vote
favorite
up vote
44
down vote
favorite
I have an executable for the perforce version control client (p4
). I can't place it in /opt/local
because I don't have root privileges. Is there a standard location where it needs to be placed under $HOME
?
Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin
?
I couldn't find such a convention mentioned on the Wikipedia article for the FHS.
Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin
directory or whatever the location of the bin
directory is?
software-installation executable directory-structure not-root-user fhs
I have an executable for the perforce version control client (p4
). I can't place it in /opt/local
because I don't have root privileges. Is there a standard location where it needs to be placed under $HOME
?
Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin
?
I couldn't find such a convention mentioned on the Wikipedia article for the FHS.
Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin
directory or whatever the location of the bin
directory is?
software-installation executable directory-structure not-root-user fhs
edited Apr 19 '12 at 22:36
Gilles
503k1179951521
503k1179951521
asked Apr 19 '12 at 14:16
user640378
4482712
4482712
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
48
down vote
accepted
In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin
. There is a complete hierarchy under /usr/local
that is generally used for locally compiled and installed software packages.
If you are the only user of a binary, installing into $HOME/bin
is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME
directory. The full local hierarchy would look like this.
$HOME/bin
Local binaries$HOME/etc
Host-specific system configuration for local binaries$HOME/games
Local game binaries$HOME/include
Local C header files$HOME/lib
Local libraries$HOME/lib64
Local 64-bit libraries$HOME/man
Local online manuals$HOME/sbin
Local system binaries$HOME/share
Local architecture-independent hierarchy$HOME/src
Local source code
When running configure
, you should define your local hierarchy for installation by specifying $HOME
as the prefix for the installation defaults.
./configure --prefix=$HOME
Now when make && make install
are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME
local hierarchy. If you have not manually created a $HOME
local hierarchy, make install
will create the directories needed by the software package.
Once installed in $HOME/bin
, you can either add $HOME/bin
to your $PATH
or call the binary using the absolute $PATH
. Some distributions will include $HOME/bin
into your $PATH
by default. You can test this by either echo $PATH
and seeing if $HOME/bin
is there, or put the binary in $HOME/bin
and executing which binaryname
. If it comes back with $HOME/bin/binaryname
, then it is in your $PATH by default.
5
as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
â ewanm89
Apr 19 '12 at 17:24
3
This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
â Patrick
Apr 19 '12 at 22:58
23
I would not recommend using$HOME
. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to haveman
,lib
, etc. in ones home dir? I would rather create the hierarchy below$HOME/bin
or$HOME/local
. That adds only one subdirectory to your home dir, instead of ten. ThePATH
can easily be adapted to include$HOME/bin/bin
or$HOME/local/bin
.
â Marco
May 3 '12 at 0:43
15
One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
â janneb
May 28 '13 at 19:20
4
@janneb The XDG Base Directory Specification you refer to mentions only$HOME/.local/share
(Version 0.7, 24th November 2010).
â Piotr Dobrogost
Nov 3 '15 at 22:06
 |Â
show 6 more comments
up vote
19
down vote
As uther mentioned, /usr/local
is intended as a prefix for, essentially, software installed by the system administrator, while /usr
should be used for software installed from the distribution's packages.
The idea behind this is to avoid clashes with distributed software (such as rpm
and deb
packages) and give the admin full reign over the "local" prefix.
This means that an admin can install custom compiled software while still using a distro like debian.
From the FHS
Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.
When installing user-specific software, uther suggests using $HOME
as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local
to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!
$HOME/.local/share
is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin
to your $PATH
and making a $HOME/.local/lib
, etc, while you're at it.
If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:
ln -s .local ~/local
Sidenote
It is worth noting that .config
(not .local/etc
) is the default value for $XDG_CONFIG_HOME
used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME
). Also note that $XDG_CONFIG_HOME
may be unset if the default $HOME/.config
is desired.
Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc
was supplied by the distro or edited by the system administrator.
1
I can't find any mention of.local
in the FHS
â Daniel Serodio
Oct 25 '17 at 17:14
@DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/⦠and superuser.com/questions/1170793/â¦
â ivan_pozdeev
Nov 7 '17 at 11:47
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
48
down vote
accepted
In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin
. There is a complete hierarchy under /usr/local
that is generally used for locally compiled and installed software packages.
If you are the only user of a binary, installing into $HOME/bin
is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME
directory. The full local hierarchy would look like this.
$HOME/bin
Local binaries$HOME/etc
Host-specific system configuration for local binaries$HOME/games
Local game binaries$HOME/include
Local C header files$HOME/lib
Local libraries$HOME/lib64
Local 64-bit libraries$HOME/man
Local online manuals$HOME/sbin
Local system binaries$HOME/share
Local architecture-independent hierarchy$HOME/src
Local source code
When running configure
, you should define your local hierarchy for installation by specifying $HOME
as the prefix for the installation defaults.
./configure --prefix=$HOME
Now when make && make install
are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME
local hierarchy. If you have not manually created a $HOME
local hierarchy, make install
will create the directories needed by the software package.
Once installed in $HOME/bin
, you can either add $HOME/bin
to your $PATH
or call the binary using the absolute $PATH
. Some distributions will include $HOME/bin
into your $PATH
by default. You can test this by either echo $PATH
and seeing if $HOME/bin
is there, or put the binary in $HOME/bin
and executing which binaryname
. If it comes back with $HOME/bin/binaryname
, then it is in your $PATH by default.
5
as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
â ewanm89
Apr 19 '12 at 17:24
3
This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
â Patrick
Apr 19 '12 at 22:58
23
I would not recommend using$HOME
. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to haveman
,lib
, etc. in ones home dir? I would rather create the hierarchy below$HOME/bin
or$HOME/local
. That adds only one subdirectory to your home dir, instead of ten. ThePATH
can easily be adapted to include$HOME/bin/bin
or$HOME/local/bin
.
â Marco
May 3 '12 at 0:43
15
One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
â janneb
May 28 '13 at 19:20
4
@janneb The XDG Base Directory Specification you refer to mentions only$HOME/.local/share
(Version 0.7, 24th November 2010).
â Piotr Dobrogost
Nov 3 '15 at 22:06
 |Â
show 6 more comments
up vote
48
down vote
accepted
In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin
. There is a complete hierarchy under /usr/local
that is generally used for locally compiled and installed software packages.
If you are the only user of a binary, installing into $HOME/bin
is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME
directory. The full local hierarchy would look like this.
$HOME/bin
Local binaries$HOME/etc
Host-specific system configuration for local binaries$HOME/games
Local game binaries$HOME/include
Local C header files$HOME/lib
Local libraries$HOME/lib64
Local 64-bit libraries$HOME/man
Local online manuals$HOME/sbin
Local system binaries$HOME/share
Local architecture-independent hierarchy$HOME/src
Local source code
When running configure
, you should define your local hierarchy for installation by specifying $HOME
as the prefix for the installation defaults.
./configure --prefix=$HOME
Now when make && make install
are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME
local hierarchy. If you have not manually created a $HOME
local hierarchy, make install
will create the directories needed by the software package.
Once installed in $HOME/bin
, you can either add $HOME/bin
to your $PATH
or call the binary using the absolute $PATH
. Some distributions will include $HOME/bin
into your $PATH
by default. You can test this by either echo $PATH
and seeing if $HOME/bin
is there, or put the binary in $HOME/bin
and executing which binaryname
. If it comes back with $HOME/bin/binaryname
, then it is in your $PATH by default.
5
as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
â ewanm89
Apr 19 '12 at 17:24
3
This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
â Patrick
Apr 19 '12 at 22:58
23
I would not recommend using$HOME
. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to haveman
,lib
, etc. in ones home dir? I would rather create the hierarchy below$HOME/bin
or$HOME/local
. That adds only one subdirectory to your home dir, instead of ten. ThePATH
can easily be adapted to include$HOME/bin/bin
or$HOME/local/bin
.
â Marco
May 3 '12 at 0:43
15
One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
â janneb
May 28 '13 at 19:20
4
@janneb The XDG Base Directory Specification you refer to mentions only$HOME/.local/share
(Version 0.7, 24th November 2010).
â Piotr Dobrogost
Nov 3 '15 at 22:06
 |Â
show 6 more comments
up vote
48
down vote
accepted
up vote
48
down vote
accepted
In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin
. There is a complete hierarchy under /usr/local
that is generally used for locally compiled and installed software packages.
If you are the only user of a binary, installing into $HOME/bin
is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME
directory. The full local hierarchy would look like this.
$HOME/bin
Local binaries$HOME/etc
Host-specific system configuration for local binaries$HOME/games
Local game binaries$HOME/include
Local C header files$HOME/lib
Local libraries$HOME/lib64
Local 64-bit libraries$HOME/man
Local online manuals$HOME/sbin
Local system binaries$HOME/share
Local architecture-independent hierarchy$HOME/src
Local source code
When running configure
, you should define your local hierarchy for installation by specifying $HOME
as the prefix for the installation defaults.
./configure --prefix=$HOME
Now when make && make install
are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME
local hierarchy. If you have not manually created a $HOME
local hierarchy, make install
will create the directories needed by the software package.
Once installed in $HOME/bin
, you can either add $HOME/bin
to your $PATH
or call the binary using the absolute $PATH
. Some distributions will include $HOME/bin
into your $PATH
by default. You can test this by either echo $PATH
and seeing if $HOME/bin
is there, or put the binary in $HOME/bin
and executing which binaryname
. If it comes back with $HOME/bin/binaryname
, then it is in your $PATH by default.
In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin
. There is a complete hierarchy under /usr/local
that is generally used for locally compiled and installed software packages.
If you are the only user of a binary, installing into $HOME/bin
is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME
directory. The full local hierarchy would look like this.
$HOME/bin
Local binaries$HOME/etc
Host-specific system configuration for local binaries$HOME/games
Local game binaries$HOME/include
Local C header files$HOME/lib
Local libraries$HOME/lib64
Local 64-bit libraries$HOME/man
Local online manuals$HOME/sbin
Local system binaries$HOME/share
Local architecture-independent hierarchy$HOME/src
Local source code
When running configure
, you should define your local hierarchy for installation by specifying $HOME
as the prefix for the installation defaults.
./configure --prefix=$HOME
Now when make && make install
are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME
local hierarchy. If you have not manually created a $HOME
local hierarchy, make install
will create the directories needed by the software package.
Once installed in $HOME/bin
, you can either add $HOME/bin
to your $PATH
or call the binary using the absolute $PATH
. Some distributions will include $HOME/bin
into your $PATH
by default. You can test this by either echo $PATH
and seeing if $HOME/bin
is there, or put the binary in $HOME/bin
and executing which binaryname
. If it comes back with $HOME/bin/binaryname
, then it is in your $PATH by default.
edited May 2 '12 at 12:22
answered Apr 19 '12 at 14:27
George M
8,69623247
8,69623247
5
as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
â ewanm89
Apr 19 '12 at 17:24
3
This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
â Patrick
Apr 19 '12 at 22:58
23
I would not recommend using$HOME
. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to haveman
,lib
, etc. in ones home dir? I would rather create the hierarchy below$HOME/bin
or$HOME/local
. That adds only one subdirectory to your home dir, instead of ten. ThePATH
can easily be adapted to include$HOME/bin/bin
or$HOME/local/bin
.
â Marco
May 3 '12 at 0:43
15
One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
â janneb
May 28 '13 at 19:20
4
@janneb The XDG Base Directory Specification you refer to mentions only$HOME/.local/share
(Version 0.7, 24th November 2010).
â Piotr Dobrogost
Nov 3 '15 at 22:06
 |Â
show 6 more comments
5
as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
â ewanm89
Apr 19 '12 at 17:24
3
This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
â Patrick
Apr 19 '12 at 22:58
23
I would not recommend using$HOME
. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to haveman
,lib
, etc. in ones home dir? I would rather create the hierarchy below$HOME/bin
or$HOME/local
. That adds only one subdirectory to your home dir, instead of ten. ThePATH
can easily be adapted to include$HOME/bin/bin
or$HOME/local/bin
.
â Marco
May 3 '12 at 0:43
15
One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
â janneb
May 28 '13 at 19:20
4
@janneb The XDG Base Directory Specification you refer to mentions only$HOME/.local/share
(Version 0.7, 24th November 2010).
â Piotr Dobrogost
Nov 3 '15 at 22:06
5
5
as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
â ewanm89
Apr 19 '12 at 17:24
as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
â ewanm89
Apr 19 '12 at 17:24
3
3
This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
â Patrick
Apr 19 '12 at 22:58
This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
â Patrick
Apr 19 '12 at 22:58
23
23
I would not recommend using
$HOME
. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man
, lib
, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin
or $HOME/local
. That adds only one subdirectory to your home dir, instead of ten. The PATH
can easily be adapted to include $HOME/bin/bin
or $HOME/local/bin
.â Marco
May 3 '12 at 0:43
I would not recommend using
$HOME
. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man
, lib
, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin
or $HOME/local
. That adds only one subdirectory to your home dir, instead of ten. The PATH
can easily be adapted to include $HOME/bin/bin
or $HOME/local/bin
.â Marco
May 3 '12 at 0:43
15
15
One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
â janneb
May 28 '13 at 19:20
One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
â janneb
May 28 '13 at 19:20
4
4
@janneb The XDG Base Directory Specification you refer to mentions only
$HOME/.local/share
(Version 0.7, 24th November 2010).â Piotr Dobrogost
Nov 3 '15 at 22:06
@janneb The XDG Base Directory Specification you refer to mentions only
$HOME/.local/share
(Version 0.7, 24th November 2010).â Piotr Dobrogost
Nov 3 '15 at 22:06
 |Â
show 6 more comments
up vote
19
down vote
As uther mentioned, /usr/local
is intended as a prefix for, essentially, software installed by the system administrator, while /usr
should be used for software installed from the distribution's packages.
The idea behind this is to avoid clashes with distributed software (such as rpm
and deb
packages) and give the admin full reign over the "local" prefix.
This means that an admin can install custom compiled software while still using a distro like debian.
From the FHS
Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.
When installing user-specific software, uther suggests using $HOME
as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local
to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!
$HOME/.local/share
is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin
to your $PATH
and making a $HOME/.local/lib
, etc, while you're at it.
If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:
ln -s .local ~/local
Sidenote
It is worth noting that .config
(not .local/etc
) is the default value for $XDG_CONFIG_HOME
used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME
). Also note that $XDG_CONFIG_HOME
may be unset if the default $HOME/.config
is desired.
Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc
was supplied by the distro or edited by the system administrator.
1
I can't find any mention of.local
in the FHS
â Daniel Serodio
Oct 25 '17 at 17:14
@DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/⦠and superuser.com/questions/1170793/â¦
â ivan_pozdeev
Nov 7 '17 at 11:47
add a comment |Â
up vote
19
down vote
As uther mentioned, /usr/local
is intended as a prefix for, essentially, software installed by the system administrator, while /usr
should be used for software installed from the distribution's packages.
The idea behind this is to avoid clashes with distributed software (such as rpm
and deb
packages) and give the admin full reign over the "local" prefix.
This means that an admin can install custom compiled software while still using a distro like debian.
From the FHS
Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.
When installing user-specific software, uther suggests using $HOME
as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local
to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!
$HOME/.local/share
is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin
to your $PATH
and making a $HOME/.local/lib
, etc, while you're at it.
If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:
ln -s .local ~/local
Sidenote
It is worth noting that .config
(not .local/etc
) is the default value for $XDG_CONFIG_HOME
used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME
). Also note that $XDG_CONFIG_HOME
may be unset if the default $HOME/.config
is desired.
Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc
was supplied by the distro or edited by the system administrator.
1
I can't find any mention of.local
in the FHS
â Daniel Serodio
Oct 25 '17 at 17:14
@DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/⦠and superuser.com/questions/1170793/â¦
â ivan_pozdeev
Nov 7 '17 at 11:47
add a comment |Â
up vote
19
down vote
up vote
19
down vote
As uther mentioned, /usr/local
is intended as a prefix for, essentially, software installed by the system administrator, while /usr
should be used for software installed from the distribution's packages.
The idea behind this is to avoid clashes with distributed software (such as rpm
and deb
packages) and give the admin full reign over the "local" prefix.
This means that an admin can install custom compiled software while still using a distro like debian.
From the FHS
Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.
When installing user-specific software, uther suggests using $HOME
as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local
to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!
$HOME/.local/share
is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin
to your $PATH
and making a $HOME/.local/lib
, etc, while you're at it.
If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:
ln -s .local ~/local
Sidenote
It is worth noting that .config
(not .local/etc
) is the default value for $XDG_CONFIG_HOME
used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME
). Also note that $XDG_CONFIG_HOME
may be unset if the default $HOME/.config
is desired.
Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc
was supplied by the distro or edited by the system administrator.
As uther mentioned, /usr/local
is intended as a prefix for, essentially, software installed by the system administrator, while /usr
should be used for software installed from the distribution's packages.
The idea behind this is to avoid clashes with distributed software (such as rpm
and deb
packages) and give the admin full reign over the "local" prefix.
This means that an admin can install custom compiled software while still using a distro like debian.
From the FHS
Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.
When installing user-specific software, uther suggests using $HOME
as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local
to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!
$HOME/.local/share
is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin
to your $PATH
and making a $HOME/.local/lib
, etc, while you're at it.
If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:
ln -s .local ~/local
Sidenote
It is worth noting that .config
(not .local/etc
) is the default value for $XDG_CONFIG_HOME
used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME
). Also note that $XDG_CONFIG_HOME
may be unset if the default $HOME/.config
is desired.
Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc
was supplied by the distro or edited by the system administrator.
edited May 29 at 5:35
Michael Homer
42.3k6108148
42.3k6108148
answered Feb 20 '16 at 3:07
MattSturgeon
38836
38836
1
I can't find any mention of.local
in the FHS
â Daniel Serodio
Oct 25 '17 at 17:14
@DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/⦠and superuser.com/questions/1170793/â¦
â ivan_pozdeev
Nov 7 '17 at 11:47
add a comment |Â
1
I can't find any mention of.local
in the FHS
â Daniel Serodio
Oct 25 '17 at 17:14
@DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/⦠and superuser.com/questions/1170793/â¦
â ivan_pozdeev
Nov 7 '17 at 11:47
1
1
I can't find any mention of
.local
in the FHSâ Daniel Serodio
Oct 25 '17 at 17:14
I can't find any mention of
.local
in the FHSâ Daniel Serodio
Oct 25 '17 at 17:14
@DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/⦠and superuser.com/questions/1170793/â¦
â ivan_pozdeev
Nov 7 '17 at 11:47
@DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/⦠and superuser.com/questions/1170793/â¦
â ivan_pozdeev
Nov 7 '17 at 11:47
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f36871%2fwhere-should-a-local-executable-be-placed%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password