Arch Linux

My opinion: No Arch package uses /usr/local/bin so if a user wants to add files there, then they should add the path.

What distributions do include it in the path?

FreeBSD? ;-)

-1 from me. Arch itself doesn't need it. If you want to use a custom place for your own stuff you should know how to deal with it. It's not our job to make life easier for people coming from another distribution.

I don't care if Fedora or any other distribution just added it to $PATH.

This bug is rather old but due to a current discussion on the mailing list I request re-opening it, because /usr/local incl. /usr/local/bin is part of the Linux
Filesystem Hierarchy Standard (FHS). So it should be supported by Arch Linux, too, and be added to $PATH. It's a minor issue, but official standards should be supported.

See also:
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/Linux-Filesystem-Hierarchy.html#usr

FHS defines file system hierarchy, not what should be in $PATH,
so not having /usr/local/bin in $PATH does not make Arch non-compliant.

I agree with Roman. Secondly, Arch does not manage config files. We never have and we never will. If you want /usr/local in there, then put it in there. We ship nothing that installs to /usr/local, thus it is useless to put it in the default PATH. My machines at home have nothing in /usr/local either. If YOU use it, then YOU edit the path.

This has nothing to do with config files. This has to do with common Linux standards and a $PATH variable which is set by the Arch Linux initscripts and/or config files anyway.
If YOU don't use /usr/local at home and if Arch Linux ships nothing that installs to /usr/local - that is obvious, because /usr/local is not meant for packages installed by a package manager - it doesn't mean that this directory isn't a Linux standard which is meant for containing system wide user scripts. And official Linux defauls should be supported by Arch Linux, too, regardless of wether YOU are using it or not. Many other people are using it.

And I really don't know why it shall hurt you to just add a simple /usr/local/bin to $PATH to fully support FHS. It's one single change for you instead of many changes for many Arch users.

And if YOU don't have anything in /usr/local at home it still doesn't hurt if /usr/local/bin is in YOUR $PATH. There will be no slowdown. If you don't want it in YOUR $PATH at home then you can remove it even if I wouldn't see the sense.

Btw., /etc/profile, where $PATH is set, is not a config file from some upstream but a config file from Arch Linux.

We have no need for adding this no matter if other use it and call it standard. And when there's no need it would break our KISS rule. -1 from me.

It's ok to be different but in this case its out right cynical. Every *nix under the sun has /usr/local/{bin,sbin} in the default PATH yet for some reason Archlinux needs to well not be Linux at all in this case. I'm all for keeping things vanilla but when it deviates from standardization and leaves a blind user scratching his head and saying WTF? Then we might have a problem.

Please find me ANY document which indicates a standard PATH value. There is no such thing.

Pro: 1) Doesn't hurt, 2) Default install paths are /usr/local/{s,}bin
Contra: 1) Arch discourages installing directly, and encourages using PKGBUILDs and installing to /usr/{s,}bin properly, so /usr/local/ should not be needed.

I don't see a problem with adding this, I think having /usr/local/{s,}bin in the path is de-facto standard among distributions. Either way, I'm happy.

This user here http://mailman.archlinux.org/pipermail/arch-general/2010-August/015506.html is a blind user. and while you feed your ego's with KISS you continue to stuff stuff like perlbin.sh in profile.d and the likes of Java. Yet you fail to meet some small standard like this. lack of documentaion of a standard PATH does not mean it is not common knowledge. Just because you dont use that PATH does not mean is should not be included.

Quit playing the pity card. It doesn't help your point. And I'm sure that the blind user wouldn't like you using his good name to garner support.

Also, stop talking about this as if it were a standard. It is not.

The user in question put their OWN script into /usr/local/bin and expected it to work. By the same token, I can go onto, say, a debian system and put my own script into /usr/sbin and it won't work either. Debian (I believe... maybe it was another distro) doesn't include the sbin directories in the PATH unless the user is root. On *all* systems you have to know what you're doing. Arch is no different.

That said, if people are really that upset about it, post a patch or something. Work begets work. Don't whine that other people aren't doing your work for you.

@Andreas: There is no more or less KISS if /usr/local/bin added to $PATH. In fact it's more KISS because a lot of people doesn't need to add it manually and for the maintainer of filesystem, which contains /etc/profile, it's just a few key strokes done in less than a minute.

@Thomas: This is not a matter of whether installing software directly or by using PKGBUILDS. I've written several shell scripts to make some system administration tasks easier. And to separate them from the packages installed by pacman and to be able to access them system wide I put them to /usr/local/bin what this directory is meant for. And I bet I'm not the only one.

@Aaron: Look at any other distribution and read the link I posted above. It is a standard.

I posted the patch over a day ago on the ML.

diff --git a/core/filesystem/profile b/core/filesystem/profile
index cf461f7..45d1839 100644
--- a/core/filesystem/profile
+++ b/core/filesystem/profile
@@ -29,7 +29,7 @@ test -f "/etc/profile.$shell" && . "/etc/profile.$shell"
umask 022

# Set our default path
-PATH="/bin:/usr/bin:/sbin:/usr/sbin"
+PATH="/usr/local/sbin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin"
export PATH

# Export default pkg-config path

@Aaron: Oh, yes, I know what I'm doing and I added /usr/local/bin to $PATH by myself. But like I said it's standard and it would make life a little bit easier for people who are using it. And it won't hurt anyone.

Heiko, your third point is actually why I also have /usr/local/bin in my path. I don't make a package for each stupid site-specific script I write, and I don't want to pollute my /usr with non-tracked files (long-term maintainability of the system and such).

If you add this to the pros, I think inclusion of /usr/local{s,}bin is acceptable.

@Heiko: That's the Filesystem Hierarchy Standard. You'd want the Single Unix Specification, specifically the "Environment Variables" subsection of the "Base Definitions" section. This contains the following for the PATH environment variable:


The sequence of path prefixes that certain functions and utilities apply in searching for an executable file known only by a filename. The prefixes are separated by a colon (:) When a non-zero-length prefix is applied to this filename, a slash is inserted between the prefix and the filename. A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent colons (::), as an initial colon preceding the rest of the list, or as a trailing colon following the rest of the list. A portable application must use an actual pathname (such as .) to represent the current working directory in PATH. The list is searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found. If the pathname being sought contains a slash, the search through the path prefixes will not be performed. If the pathname begins with a slash, the specified path is resolved (see pathname resolution ). If PATH is unset or is set to null, the path search is implementation-dependent.

Although under BSD systems and other Unixes it's standard to have /usr/local/{s,}bin in PATH, I can't see any reason why should a Linux distribution include these directories. Pretty much all binaries in Linux distros belong to some easily replacable package.

The few people who actually need it can change the PATH environment variable themselves. It's easy.

If we cared about "standards" we would be using RPM as dictated by the Linux Standards Base.

Has anything actually changed since we last closed this as "Won't Fix"? I see nothing to convince me to add it. In fact complaining that you put scripts in /usr/local/bin and they do not run actually wants me to keep it out. I'd prefer some sort of competence among Arch users and setting the bar at being able to adjust the PATH is quite a low one...

Since when is RPM a standard or is it dictated? There are only a few distros which are using RPM and many which are using different package formats.
And I don't think that this has anything to do with competence. Not to mention that more and more normal users will be using Arch Linux in the future. So I don't think that Arch Linux is just for Linux professionals. But that's not the point of this issue.

Like I said I was able to add /usr/local/bin to $PATH by myself. Otherwise I had opened a or re-opened this bug a few years ago. So I don't think that this is the question.

@Allan I think you and I both know this is not a competence issue. If anything I would argue the type of person that would expect it to be there, might be someone that has been around the block enough to know that most if not all *nix type systems have this in the default PATH.

I would rather hear the real reason for not adding it. Which is "we would like to add it, and we think it should add it" however the reason we dont is because it confuses new users when they build software by hand. We would rather promote the use of PKGBUILD's . However as nice as PKGBUIlD's are they do not cover all basis. Which is exactly what /usr/local is for.

@Heiko: http://www.linuxfoundation.org/collaborate/workgroups/lsb The LSB standard, provided by the Linux Foundation, says RPM is standard

@Aaron: http://ldn.linuxfoundation.org/lsb/porting-lsb-demo

"Package your application.

LSB-conforming systems promise to be able to install an LSB-compliant RPM. However, you need not limit yourself to that format, with the caveat that the packaging technology you choose must work on an LSB-compliant system. For example, a compliant shell script with a tarball is an acceptable format. Your own installer is acceptable, too, as long as the installer itself is LSB compliant."

So they declare rpm as a standard but tar.* as in Arch Linux is LSB compliant, too. They also mention deb somewhere else. And it is possible to install rpm packages on Arch Linux. If this makes sense and if this is the recommended way for installing packages on Arch is a different question. And I bet that the Arch packages can principally be installed on other distros, too.

@Heiko:
Here is my PATH from a RHEL 5 installation:
/home/lisaev/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/cern/2003/bin:/cern/2003/include:/cern/2003/lib:/cern/root/bin:/cern/pro/bin:/opt/grace/bin

As you can see, there is /usr/local/bin, but no /sbin and /usr/sbin. Meanwhile, the latter two dirs are also a standard, according to you... Have you seen a bug report to RH's bugzilla against this issue?

We do have /sbin:/usr/sbin in the default PATH. If you want to change something in /etc/profile, removal of these will actually be useful from the security standpoint.