What is /usr/local/bin?
Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch
command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755
the file to make it executable afterwards.
I'd like to know what /usr/local/bin
is, though. /usr/
, I assume, is the user of the computer. I'm not sure why /local/
is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin
be fine?
And what is /bin
? Why is this area usually used for installing scripts onto the terminal?
executable directory-structure
add a comment |
Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch
command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755
the file to make it executable afterwards.
I'd like to know what /usr/local/bin
is, though. /usr/
, I assume, is the user of the computer. I'm not sure why /local/
is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin
be fine?
And what is /bin
? Why is this area usually used for installing scripts onto the terminal?
executable directory-structure
add a comment |
Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch
command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755
the file to make it executable afterwards.
I'd like to know what /usr/local/bin
is, though. /usr/
, I assume, is the user of the computer. I'm not sure why /local/
is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin
be fine?
And what is /bin
? Why is this area usually used for installing scripts onto the terminal?
executable directory-structure
Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch
command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755
the file to make it executable afterwards.
I'd like to know what /usr/local/bin
is, though. /usr/
, I assume, is the user of the computer. I'm not sure why /local/
is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin
be fine?
And what is /bin
? Why is this area usually used for installing scripts onto the terminal?
executable directory-structure
executable directory-structure
edited Nov 2 '15 at 5:16
Thomas Weinbrenner
2,66721131
2,66721131
asked Nov 18 '10 at 13:49
JFWJFW
8071911
8071911
add a comment |
add a comment |
9 Answers
9
active
oldest
votes
/usr/local/bin
is for programs that a normal user may run.
- The
/usr/local
hierarchy is for use by the system administrator when installing software locally. - It needs to be safe from being overwritten when the system software is updated.
- It may be used for programs and data that
are shareable amongst a group of hosts, but not found in/usr
. - Locally installed software must be placed within
/usr/local
rather than /usr unless it is being installed to
replace or upgrade software in/usr
.
This source helps explain the filesystem hierarchy standard on a deeper level.
You might find this article on the use and abuse of /usr/local/bin
interesting as well.
"""unless it is being installed to replace or upgrade software in /usr""" meaning?
– Pacerier
Nov 1 '17 at 21:35
add a comment |
/usr/, I assume is the user of the computer.
Close.
Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.
Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home
, the conventional location was /usr
.¹ Your $HOME
directory might have been /usr/jfw
on a System III box.
/usr
also contained, then as now, /usr/bin
, /usr/lib
, etc. Experience showed that segregating the home directories was good system management practice, so with the /home
policy change in SVR4, it left behind everything we now think of as belonging in /usr
.
/usr
still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr
could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.
Early Unix systems were careful to keep the core OS files out of /usr
so that you could still boot into single-user mode² even if the /usr
volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr
volume back online.
Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr
on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin
to /usr/bin
and /lib
to /usr/lib
so that there is no longer any difference between these directories.
.../local/...obviously stands for the local computer...
Yes. It refers to the fact that files under /usr/local
are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.
This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr
over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local
, which would be a separate volume from /usr
.
This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local
when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.
There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash
from the GNU Bash source code. They use /
as the installation prefix, overriding the /usr/local
default, so that Bash ends up in /bin
.
Another example is the way older Linux systems segregated their GUI software into /usr/X11R6
, to keep it separate from the traditional command line and curses
-based software. This was done simply by overriding the default /usr/local
prefix with /usr/X11R6
.⁵
And what is /bin?
It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")
Text files on a Unix box live elsewhere: /etc
, /usr/include
, /usr/share
, etc.
Once upon a time, even shell scripts — which are plain text files — were kept out of bin
directories, but this line, too, has blurred. Today, bin
directories typically contain any kind of executable file, whether strictly "binary" or not.⁶
Footnotes and Digressions:
The primitive nature of the user management tools prior to SVR4 meant that the
HOME=/usr/$NAME
scheme was merely documented as a convention, rather than enforced by software tools as a default.
You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old
/usr/$NAME
scheme in the last major version of Unix before SVR4 came out.
It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.
One scheme I came across before
/home/$NAME
became the standard was/u/$NAME
.
Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like
/u1/$NAME
,/u2/$NAME
, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.
You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.
Be careful, you're running as
root
.
Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.
Unixy OSes that still appear to keep critical single-user mode files out of
/usr
may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving/usr
to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in/usr
in order to mount/usr
!
That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of
/usr
, I could have fixed it in place. Since it wouldn't boot even to single-user mode with/usr
being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.
This is also where we get
/usr/share
: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc."X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.
The original Unix systems kept their core shell scripts in
/etc
in order to avoid commingling them with the true binaries in/bin
.
1
Loved that picture of washing machine!
– asgs
Oct 12 '17 at 20:18
@Warren, What are the notable OSes before System III?
– Pacerier
Nov 1 '17 at 20:59
@Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?
– Warren Young
Nov 1 '17 at 21:33
@Warren, Well, they might have affected the defacto "directory naming system" somehow
– Pacerier
Nov 1 '17 at 21:34
@Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.
– Warren Young
Nov 1 '17 at 21:35
|
show 4 more comments
I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.
To answer your question directly, however:
- /usr is, loosely, non-critical system libraries and executables
- /usr/local is, again loosely, for non-system libraries and executables
This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing
ls -ld /usr/{,local/}{bin,sbin,lib}
from your local shell to see how it works.
add a comment |
/usr/local/bin
shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).
- "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.
- "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.
- "bin" represents binary compiled executables.
This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin
would be for "main" or core programs and libraries where /usr/local/bin
would be for add-on and non-critical programs and libraries.
11
I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be/usr/nzwulfin
by default. Another common scheme. before the SVR4/home
scheme took over, was/u
. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like/u/d5/tangent
.
– Warren Young
Nov 18 '10 at 17:54
3
@Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms
– Michael Mrozek♦
Nov 19 '10 at 23:35
add a comment |
/usr/local/bin
is the most popular default location for executable files, especially open source ones.
This is however arguably a poor choice as, on Unix systems, /usr
has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.
As these files are static, the /usr
file system can be mounted read-only. /usr/local
is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local
wasn't chosen instead ...
add a comment |
On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.
add a comment |
I recommend you use /usr/local
for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.
Separately, make sure you give /home
its own partition for this reason too.
add a comment |
This answer might be helpful as well.
/usr/local
The original idea behind /usr/local
was to have a separate ('local') '/usr' directory on every machine besides /usr
, which might be just mounted read-only from somewhere else. It copies the structure of /usr
.
These days, /usr/local
is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local
hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.
It may be used for programs and data that are shared among a group of hosts, but not found in /usr
. Locally installed software must be placed within /usr/local
rather than /usr
unless it is being installed to replace or upgrade software in /usr
.
add a comment |
usr==user?
I think usr
stands for Unix System Resource
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f4186%2fwhat-is-usr-local-bin%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
/usr/local/bin
is for programs that a normal user may run.
- The
/usr/local
hierarchy is for use by the system administrator when installing software locally. - It needs to be safe from being overwritten when the system software is updated.
- It may be used for programs and data that
are shareable amongst a group of hosts, but not found in/usr
. - Locally installed software must be placed within
/usr/local
rather than /usr unless it is being installed to
replace or upgrade software in/usr
.
This source helps explain the filesystem hierarchy standard on a deeper level.
You might find this article on the use and abuse of /usr/local/bin
interesting as well.
"""unless it is being installed to replace or upgrade software in /usr""" meaning?
– Pacerier
Nov 1 '17 at 21:35
add a comment |
/usr/local/bin
is for programs that a normal user may run.
- The
/usr/local
hierarchy is for use by the system administrator when installing software locally. - It needs to be safe from being overwritten when the system software is updated.
- It may be used for programs and data that
are shareable amongst a group of hosts, but not found in/usr
. - Locally installed software must be placed within
/usr/local
rather than /usr unless it is being installed to
replace or upgrade software in/usr
.
This source helps explain the filesystem hierarchy standard on a deeper level.
You might find this article on the use and abuse of /usr/local/bin
interesting as well.
"""unless it is being installed to replace or upgrade software in /usr""" meaning?
– Pacerier
Nov 1 '17 at 21:35
add a comment |
/usr/local/bin
is for programs that a normal user may run.
- The
/usr/local
hierarchy is for use by the system administrator when installing software locally. - It needs to be safe from being overwritten when the system software is updated.
- It may be used for programs and data that
are shareable amongst a group of hosts, but not found in/usr
. - Locally installed software must be placed within
/usr/local
rather than /usr unless it is being installed to
replace or upgrade software in/usr
.
This source helps explain the filesystem hierarchy standard on a deeper level.
You might find this article on the use and abuse of /usr/local/bin
interesting as well.
/usr/local/bin
is for programs that a normal user may run.
- The
/usr/local
hierarchy is for use by the system administrator when installing software locally. - It needs to be safe from being overwritten when the system software is updated.
- It may be used for programs and data that
are shareable amongst a group of hosts, but not found in/usr
. - Locally installed software must be placed within
/usr/local
rather than /usr unless it is being installed to
replace or upgrade software in/usr
.
This source helps explain the filesystem hierarchy standard on a deeper level.
You might find this article on the use and abuse of /usr/local/bin
interesting as well.
edited Nov 13 '14 at 6:56
JakeGould
1698
1698
answered Nov 18 '10 at 14:09
iamsidiamsid
1,8161817
1,8161817
"""unless it is being installed to replace or upgrade software in /usr""" meaning?
– Pacerier
Nov 1 '17 at 21:35
add a comment |
"""unless it is being installed to replace or upgrade software in /usr""" meaning?
– Pacerier
Nov 1 '17 at 21:35
"""unless it is being installed to replace or upgrade software in /usr""" meaning?
– Pacerier
Nov 1 '17 at 21:35
"""unless it is being installed to replace or upgrade software in /usr""" meaning?
– Pacerier
Nov 1 '17 at 21:35
add a comment |
/usr/, I assume is the user of the computer.
Close.
Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.
Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home
, the conventional location was /usr
.¹ Your $HOME
directory might have been /usr/jfw
on a System III box.
/usr
also contained, then as now, /usr/bin
, /usr/lib
, etc. Experience showed that segregating the home directories was good system management practice, so with the /home
policy change in SVR4, it left behind everything we now think of as belonging in /usr
.
/usr
still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr
could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.
Early Unix systems were careful to keep the core OS files out of /usr
so that you could still boot into single-user mode² even if the /usr
volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr
volume back online.
Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr
on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin
to /usr/bin
and /lib
to /usr/lib
so that there is no longer any difference between these directories.
.../local/...obviously stands for the local computer...
Yes. It refers to the fact that files under /usr/local
are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.
This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr
over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local
, which would be a separate volume from /usr
.
This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local
when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.
There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash
from the GNU Bash source code. They use /
as the installation prefix, overriding the /usr/local
default, so that Bash ends up in /bin
.
Another example is the way older Linux systems segregated their GUI software into /usr/X11R6
, to keep it separate from the traditional command line and curses
-based software. This was done simply by overriding the default /usr/local
prefix with /usr/X11R6
.⁵
And what is /bin?
It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")
Text files on a Unix box live elsewhere: /etc
, /usr/include
, /usr/share
, etc.
Once upon a time, even shell scripts — which are plain text files — were kept out of bin
directories, but this line, too, has blurred. Today, bin
directories typically contain any kind of executable file, whether strictly "binary" or not.⁶
Footnotes and Digressions:
The primitive nature of the user management tools prior to SVR4 meant that the
HOME=/usr/$NAME
scheme was merely documented as a convention, rather than enforced by software tools as a default.
You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old
/usr/$NAME
scheme in the last major version of Unix before SVR4 came out.
It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.
One scheme I came across before
/home/$NAME
became the standard was/u/$NAME
.
Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like
/u1/$NAME
,/u2/$NAME
, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.
You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.
Be careful, you're running as
root
.
Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.
Unixy OSes that still appear to keep critical single-user mode files out of
/usr
may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving/usr
to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in/usr
in order to mount/usr
!
That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of
/usr
, I could have fixed it in place. Since it wouldn't boot even to single-user mode with/usr
being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.
This is also where we get
/usr/share
: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc."X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.
The original Unix systems kept their core shell scripts in
/etc
in order to avoid commingling them with the true binaries in/bin
.
1
Loved that picture of washing machine!
– asgs
Oct 12 '17 at 20:18
@Warren, What are the notable OSes before System III?
– Pacerier
Nov 1 '17 at 20:59
@Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?
– Warren Young
Nov 1 '17 at 21:33
@Warren, Well, they might have affected the defacto "directory naming system" somehow
– Pacerier
Nov 1 '17 at 21:34
@Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.
– Warren Young
Nov 1 '17 at 21:35
|
show 4 more comments
/usr/, I assume is the user of the computer.
Close.
Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.
Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home
, the conventional location was /usr
.¹ Your $HOME
directory might have been /usr/jfw
on a System III box.
/usr
also contained, then as now, /usr/bin
, /usr/lib
, etc. Experience showed that segregating the home directories was good system management practice, so with the /home
policy change in SVR4, it left behind everything we now think of as belonging in /usr
.
/usr
still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr
could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.
Early Unix systems were careful to keep the core OS files out of /usr
so that you could still boot into single-user mode² even if the /usr
volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr
volume back online.
Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr
on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin
to /usr/bin
and /lib
to /usr/lib
so that there is no longer any difference between these directories.
.../local/...obviously stands for the local computer...
Yes. It refers to the fact that files under /usr/local
are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.
This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr
over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local
, which would be a separate volume from /usr
.
This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local
when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.
There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash
from the GNU Bash source code. They use /
as the installation prefix, overriding the /usr/local
default, so that Bash ends up in /bin
.
Another example is the way older Linux systems segregated their GUI software into /usr/X11R6
, to keep it separate from the traditional command line and curses
-based software. This was done simply by overriding the default /usr/local
prefix with /usr/X11R6
.⁵
And what is /bin?
It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")
Text files on a Unix box live elsewhere: /etc
, /usr/include
, /usr/share
, etc.
Once upon a time, even shell scripts — which are plain text files — were kept out of bin
directories, but this line, too, has blurred. Today, bin
directories typically contain any kind of executable file, whether strictly "binary" or not.⁶
Footnotes and Digressions:
The primitive nature of the user management tools prior to SVR4 meant that the
HOME=/usr/$NAME
scheme was merely documented as a convention, rather than enforced by software tools as a default.
You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old
/usr/$NAME
scheme in the last major version of Unix before SVR4 came out.
It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.
One scheme I came across before
/home/$NAME
became the standard was/u/$NAME
.
Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like
/u1/$NAME
,/u2/$NAME
, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.
You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.
Be careful, you're running as
root
.
Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.
Unixy OSes that still appear to keep critical single-user mode files out of
/usr
may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving/usr
to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in/usr
in order to mount/usr
!
That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of
/usr
, I could have fixed it in place. Since it wouldn't boot even to single-user mode with/usr
being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.
This is also where we get
/usr/share
: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc."X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.
The original Unix systems kept their core shell scripts in
/etc
in order to avoid commingling them with the true binaries in/bin
.
1
Loved that picture of washing machine!
– asgs
Oct 12 '17 at 20:18
@Warren, What are the notable OSes before System III?
– Pacerier
Nov 1 '17 at 20:59
@Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?
– Warren Young
Nov 1 '17 at 21:33
@Warren, Well, they might have affected the defacto "directory naming system" somehow
– Pacerier
Nov 1 '17 at 21:34
@Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.
– Warren Young
Nov 1 '17 at 21:35
|
show 4 more comments
/usr/, I assume is the user of the computer.
Close.
Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.
Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home
, the conventional location was /usr
.¹ Your $HOME
directory might have been /usr/jfw
on a System III box.
/usr
also contained, then as now, /usr/bin
, /usr/lib
, etc. Experience showed that segregating the home directories was good system management practice, so with the /home
policy change in SVR4, it left behind everything we now think of as belonging in /usr
.
/usr
still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr
could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.
Early Unix systems were careful to keep the core OS files out of /usr
so that you could still boot into single-user mode² even if the /usr
volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr
volume back online.
Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr
on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin
to /usr/bin
and /lib
to /usr/lib
so that there is no longer any difference between these directories.
.../local/...obviously stands for the local computer...
Yes. It refers to the fact that files under /usr/local
are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.
This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr
over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local
, which would be a separate volume from /usr
.
This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local
when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.
There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash
from the GNU Bash source code. They use /
as the installation prefix, overriding the /usr/local
default, so that Bash ends up in /bin
.
Another example is the way older Linux systems segregated their GUI software into /usr/X11R6
, to keep it separate from the traditional command line and curses
-based software. This was done simply by overriding the default /usr/local
prefix with /usr/X11R6
.⁵
And what is /bin?
It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")
Text files on a Unix box live elsewhere: /etc
, /usr/include
, /usr/share
, etc.
Once upon a time, even shell scripts — which are plain text files — were kept out of bin
directories, but this line, too, has blurred. Today, bin
directories typically contain any kind of executable file, whether strictly "binary" or not.⁶
Footnotes and Digressions:
The primitive nature of the user management tools prior to SVR4 meant that the
HOME=/usr/$NAME
scheme was merely documented as a convention, rather than enforced by software tools as a default.
You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old
/usr/$NAME
scheme in the last major version of Unix before SVR4 came out.
It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.
One scheme I came across before
/home/$NAME
became the standard was/u/$NAME
.
Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like
/u1/$NAME
,/u2/$NAME
, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.
You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.
Be careful, you're running as
root
.
Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.
Unixy OSes that still appear to keep critical single-user mode files out of
/usr
may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving/usr
to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in/usr
in order to mount/usr
!
That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of
/usr
, I could have fixed it in place. Since it wouldn't boot even to single-user mode with/usr
being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.
This is also where we get
/usr/share
: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc."X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.
The original Unix systems kept their core shell scripts in
/etc
in order to avoid commingling them with the true binaries in/bin
.
/usr/, I assume is the user of the computer.
Close.
Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.
Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home
, the conventional location was /usr
.¹ Your $HOME
directory might have been /usr/jfw
on a System III box.
/usr
also contained, then as now, /usr/bin
, /usr/lib
, etc. Experience showed that segregating the home directories was good system management practice, so with the /home
policy change in SVR4, it left behind everything we now think of as belonging in /usr
.
/usr
still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr
could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.
Early Unix systems were careful to keep the core OS files out of /usr
so that you could still boot into single-user mode² even if the /usr
volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr
volume back online.
Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr
on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin
to /usr/bin
and /lib
to /usr/lib
so that there is no longer any difference between these directories.
.../local/...obviously stands for the local computer...
Yes. It refers to the fact that files under /usr/local
are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.
This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr
over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local
, which would be a separate volume from /usr
.
This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local
when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.
There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash
from the GNU Bash source code. They use /
as the installation prefix, overriding the /usr/local
default, so that Bash ends up in /bin
.
Another example is the way older Linux systems segregated their GUI software into /usr/X11R6
, to keep it separate from the traditional command line and curses
-based software. This was done simply by overriding the default /usr/local
prefix with /usr/X11R6
.⁵
And what is /bin?
It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")
Text files on a Unix box live elsewhere: /etc
, /usr/include
, /usr/share
, etc.
Once upon a time, even shell scripts — which are plain text files — were kept out of bin
directories, but this line, too, has blurred. Today, bin
directories typically contain any kind of executable file, whether strictly "binary" or not.⁶
Footnotes and Digressions:
The primitive nature of the user management tools prior to SVR4 meant that the
HOME=/usr/$NAME
scheme was merely documented as a convention, rather than enforced by software tools as a default.
You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old
/usr/$NAME
scheme in the last major version of Unix before SVR4 came out.
It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.
One scheme I came across before
/home/$NAME
became the standard was/u/$NAME
.
Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like
/u1/$NAME
,/u2/$NAME
, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.
You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.
Be careful, you're running as
root
.
Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.
Unixy OSes that still appear to keep critical single-user mode files out of
/usr
may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving/usr
to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in/usr
in order to mount/usr
!
That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of
/usr
, I could have fixed it in place. Since it wouldn't boot even to single-user mode with/usr
being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.
This is also where we get
/usr/share
: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc."X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.
The original Unix systems kept their core shell scripts in
/etc
in order to avoid commingling them with the true binaries in/bin
.
edited Sep 21 '18 at 16:51
answered Nov 18 '10 at 18:34
Warren YoungWarren Young
55k11143147
55k11143147
1
Loved that picture of washing machine!
– asgs
Oct 12 '17 at 20:18
@Warren, What are the notable OSes before System III?
– Pacerier
Nov 1 '17 at 20:59
@Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?
– Warren Young
Nov 1 '17 at 21:33
@Warren, Well, they might have affected the defacto "directory naming system" somehow
– Pacerier
Nov 1 '17 at 21:34
@Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.
– Warren Young
Nov 1 '17 at 21:35
|
show 4 more comments
1
Loved that picture of washing machine!
– asgs
Oct 12 '17 at 20:18
@Warren, What are the notable OSes before System III?
– Pacerier
Nov 1 '17 at 20:59
@Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?
– Warren Young
Nov 1 '17 at 21:33
@Warren, Well, they might have affected the defacto "directory naming system" somehow
– Pacerier
Nov 1 '17 at 21:34
@Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.
– Warren Young
Nov 1 '17 at 21:35
1
1
Loved that picture of washing machine!
– asgs
Oct 12 '17 at 20:18
Loved that picture of washing machine!
– asgs
Oct 12 '17 at 20:18
@Warren, What are the notable OSes before System III?
– Pacerier
Nov 1 '17 at 20:59
@Warren, What are the notable OSes before System III?
– Pacerier
Nov 1 '17 at 20:59
@Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?
– Warren Young
Nov 1 '17 at 21:33
@Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?
– Warren Young
Nov 1 '17 at 21:33
@Warren, Well, they might have affected the defacto "directory naming system" somehow
– Pacerier
Nov 1 '17 at 21:34
@Warren, Well, they might have affected the defacto "directory naming system" somehow
– Pacerier
Nov 1 '17 at 21:34
@Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.
– Warren Young
Nov 1 '17 at 21:35
@Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.
– Warren Young
Nov 1 '17 at 21:35
|
show 4 more comments
I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.
To answer your question directly, however:
- /usr is, loosely, non-critical system libraries and executables
- /usr/local is, again loosely, for non-system libraries and executables
This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing
ls -ld /usr/{,local/}{bin,sbin,lib}
from your local shell to see how it works.
add a comment |
I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.
To answer your question directly, however:
- /usr is, loosely, non-critical system libraries and executables
- /usr/local is, again loosely, for non-system libraries and executables
This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing
ls -ld /usr/{,local/}{bin,sbin,lib}
from your local shell to see how it works.
add a comment |
I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.
To answer your question directly, however:
- /usr is, loosely, non-critical system libraries and executables
- /usr/local is, again loosely, for non-system libraries and executables
This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing
ls -ld /usr/{,local/}{bin,sbin,lib}
from your local shell to see how it works.
I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.
To answer your question directly, however:
- /usr is, loosely, non-critical system libraries and executables
- /usr/local is, again loosely, for non-system libraries and executables
This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing
ls -ld /usr/{,local/}{bin,sbin,lib}
from your local shell to see how it works.
answered Nov 18 '10 at 14:11
TokTok
6,99421810
6,99421810
add a comment |
add a comment |
/usr/local/bin
shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).
- "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.
- "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.
- "bin" represents binary compiled executables.
This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin
would be for "main" or core programs and libraries where /usr/local/bin
would be for add-on and non-critical programs and libraries.
11
I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be/usr/nzwulfin
by default. Another common scheme. before the SVR4/home
scheme took over, was/u
. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like/u/d5/tangent
.
– Warren Young
Nov 18 '10 at 17:54
3
@Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms
– Michael Mrozek♦
Nov 19 '10 at 23:35
add a comment |
/usr/local/bin
shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).
- "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.
- "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.
- "bin" represents binary compiled executables.
This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin
would be for "main" or core programs and libraries where /usr/local/bin
would be for add-on and non-critical programs and libraries.
11
I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be/usr/nzwulfin
by default. Another common scheme. before the SVR4/home
scheme took over, was/u
. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like/u/d5/tangent
.
– Warren Young
Nov 18 '10 at 17:54
3
@Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms
– Michael Mrozek♦
Nov 19 '10 at 23:35
add a comment |
/usr/local/bin
shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).
- "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.
- "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.
- "bin" represents binary compiled executables.
This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin
would be for "main" or core programs and libraries where /usr/local/bin
would be for add-on and non-critical programs and libraries.
/usr/local/bin
shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).
- "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.
- "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.
- "bin" represents binary compiled executables.
This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin
would be for "main" or core programs and libraries where /usr/local/bin
would be for add-on and non-critical programs and libraries.
edited Nov 19 '14 at 19:04
slm♦
250k66523683
250k66523683
answered Nov 18 '10 at 14:12
nzwulfinnzwulfin
67743
67743
11
I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be/usr/nzwulfin
by default. Another common scheme. before the SVR4/home
scheme took over, was/u
. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like/u/d5/tangent
.
– Warren Young
Nov 18 '10 at 17:54
3
@Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms
– Michael Mrozek♦
Nov 19 '10 at 23:35
add a comment |
11
I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be/usr/nzwulfin
by default. Another common scheme. before the SVR4/home
scheme took over, was/u
. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like/u/d5/tangent
.
– Warren Young
Nov 18 '10 at 17:54
3
@Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms
– Michael Mrozek♦
Nov 19 '10 at 23:35
11
11
I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be
/usr/nzwulfin
by default. Another common scheme. before the SVR4 /home
scheme took over, was /u
. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent
.– Warren Young
Nov 18 '10 at 17:54
I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be
/usr/nzwulfin
by default. Another common scheme. before the SVR4 /home
scheme took over, was /u
. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent
.– Warren Young
Nov 18 '10 at 17:54
3
3
@Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms
– Michael Mrozek♦
Nov 19 '10 at 23:35
@Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms
– Michael Mrozek♦
Nov 19 '10 at 23:35
add a comment |
/usr/local/bin
is the most popular default location for executable files, especially open source ones.
This is however arguably a poor choice as, on Unix systems, /usr
has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.
As these files are static, the /usr
file system can be mounted read-only. /usr/local
is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local
wasn't chosen instead ...
add a comment |
/usr/local/bin
is the most popular default location for executable files, especially open source ones.
This is however arguably a poor choice as, on Unix systems, /usr
has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.
As these files are static, the /usr
file system can be mounted read-only. /usr/local
is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local
wasn't chosen instead ...
add a comment |
/usr/local/bin
is the most popular default location for executable files, especially open source ones.
This is however arguably a poor choice as, on Unix systems, /usr
has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.
As these files are static, the /usr
file system can be mounted read-only. /usr/local
is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local
wasn't chosen instead ...
/usr/local/bin
is the most popular default location for executable files, especially open source ones.
This is however arguably a poor choice as, on Unix systems, /usr
has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.
As these files are static, the /usr
file system can be mounted read-only. /usr/local
is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local
wasn't chosen instead ...
edited Nov 19 '14 at 19:07
slm♦
250k66523683
250k66523683
answered Nov 18 '10 at 22:39
jlliagrejlliagre
46.9k783133
46.9k783133
add a comment |
add a comment |
On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.
add a comment |
On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.
add a comment |
On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.
On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.
answered Nov 30 '13 at 4:23
voidstatevoidstate
1112
1112
add a comment |
add a comment |
I recommend you use /usr/local
for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.
Separately, make sure you give /home
its own partition for this reason too.
add a comment |
I recommend you use /usr/local
for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.
Separately, make sure you give /home
its own partition for this reason too.
add a comment |
I recommend you use /usr/local
for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.
Separately, make sure you give /home
its own partition for this reason too.
I recommend you use /usr/local
for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.
Separately, make sure you give /home
its own partition for this reason too.
edited Nov 19 '14 at 19:03
slm♦
250k66523683
250k66523683
answered Jul 4 '11 at 0:46
ncmathsadistncmathsadist
1293
1293
add a comment |
add a comment |
This answer might be helpful as well.
/usr/local
The original idea behind /usr/local
was to have a separate ('local') '/usr' directory on every machine besides /usr
, which might be just mounted read-only from somewhere else. It copies the structure of /usr
.
These days, /usr/local
is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local
hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.
It may be used for programs and data that are shared among a group of hosts, but not found in /usr
. Locally installed software must be placed within /usr/local
rather than /usr
unless it is being installed to replace or upgrade software in /usr
.
add a comment |
This answer might be helpful as well.
/usr/local
The original idea behind /usr/local
was to have a separate ('local') '/usr' directory on every machine besides /usr
, which might be just mounted read-only from somewhere else. It copies the structure of /usr
.
These days, /usr/local
is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local
hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.
It may be used for programs and data that are shared among a group of hosts, but not found in /usr
. Locally installed software must be placed within /usr/local
rather than /usr
unless it is being installed to replace or upgrade software in /usr
.
add a comment |
This answer might be helpful as well.
/usr/local
The original idea behind /usr/local
was to have a separate ('local') '/usr' directory on every machine besides /usr
, which might be just mounted read-only from somewhere else. It copies the structure of /usr
.
These days, /usr/local
is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local
hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.
It may be used for programs and data that are shared among a group of hosts, but not found in /usr
. Locally installed software must be placed within /usr/local
rather than /usr
unless it is being installed to replace or upgrade software in /usr
.
This answer might be helpful as well.
/usr/local
The original idea behind /usr/local
was to have a separate ('local') '/usr' directory on every machine besides /usr
, which might be just mounted read-only from somewhere else. It copies the structure of /usr
.
These days, /usr/local
is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local
hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.
It may be used for programs and data that are shared among a group of hosts, but not found in /usr
. Locally installed software must be placed within /usr/local
rather than /usr
unless it is being installed to replace or upgrade software in /usr
.
edited Nov 19 '14 at 19:02
slm♦
250k66523683
250k66523683
answered Oct 21 '14 at 3:59
Vishwanath gowda kVishwanath gowda k
34039
34039
add a comment |
add a comment |
usr==user?
I think usr
stands for Unix System Resource
New contributor
add a comment |
usr==user?
I think usr
stands for Unix System Resource
New contributor
add a comment |
usr==user?
I think usr
stands for Unix System Resource
New contributor
usr==user?
I think usr
stands for Unix System Resource
New contributor
New contributor
answered 3 mins ago
AliarAliar
1
1
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f4186%2fwhat-is-usr-local-bin%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown