Le dimanche 15 août 2010 11:20:33, Allan McRae a écrit :

On 15/08/10 18:50, Jude DaShiell wrote:

...

In order for that to be correct it needs to also have :/usr/local/bin inside of the quote marks. The /usr/local/bin directory on Linux systems like slackware and debian is where stuff gets put that anyone can execute that's on the system. I put a simple shell script I wrote there then tried to use it and it wouldn't work until I keyed in the /usr/local/bin/myd command. That small script makes the date and time more readable for me. Since that file was copied from suse, people in that other distribution probably also ought to be notified.

What is wrong with not including that? If the system administrator can install files to /usr/local/bin then I am sure that they are competent enough to add that to their path.

Allan

And as an user you can add the path in your .bashrc/.... ++

On Sun, Aug 15, 2010 at 5:44 AM, Heiko Baums wrote:

Am Sun, 15 Aug 2010 11:21:24 +0200 schrieb Laurent Carlier :

...

Le dimanche 15 août 2010 11:20:33, Allan McRae a écrit :

...

On 15/08/10 18:50, Jude DaShiell wrote:

...

In order for that to be correct it needs to also have :/usr/local/bin inside of the quote marks. The /usr/local/bin directory on Linux systems like slackware and debian is where stuff gets put that anyone can execute that's on the system. I put a simple shell script I wrote there then tried to use it and it wouldn't work until I keyed in the /usr/local/bin/myd command. That small script makes the date and time more readable for me. Since that file was copied from suse, people in that other distribution probably also ought to be notified.

What is wrong with not including that?  If the system administrator can install files to /usr/local/bin then I am sure that they are competent enough to add that to their path.

Allan

And as an user you can add the path in your .bashrc/....

++

Of course they can, but Jude is not completely wrong with that, because /usr/local and /usr/local/bin are part of the official Linux Filesystem Hierarchy Standard (FHS). So it's an official path for local scripts and binaries, which are e.g. written by the administrator. And official paths, even if the package manager doesn't touch them, and standards should be officially supported by Arch, too.

And why does it hurt adding this directory to the PATH?

From http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/Linux-Filesystem-Hierarc...:

"/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 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."

Heiko

I agree with this /usr/local/ is a pretty common location to install system wide software and imo /usr/local/bin /usr/local/sbin should be included in the default path. FHS covers this and GNU conf also defaults to this. However in Judd's case I would think ~/bin would be better suited for user scripts unless he needs to use them system wide ie. as another user. since its much easier to edit save the files and does not require root privileges to modify Mike

I use ~/.local/bin for user specific applications and scripts. ~/bin would create visible clutter to the home folder.

-- Ape <Lauri Niskanen>

That might work for you however in Jude's case being a blind user I would think he would want something that is very visible in a braille terminal. Either way I'm sure he can find something that works for him. But this also derails from the topic of /usr/local which is still a valid point. MIke

Someone unaware of dotfiles might miss them, but others (blind or sighted) should be able to access them without issue.

And all of this has nothing to do with the orignal issue /usr/local. I only suggested using something in $HOME for "user" based scripts which can be anything it does not matter. It only serves to deflect from why is /usr/local/{bin,sbin} not part of the default search PATH? when its a FHS standard and has always been used for custom system wide installs? Obviously a competent system administrator can add this. However does this mean we should remove /usr/bin now to? since any competent admin can add that also. Mike

On Sun, Aug 15, 2010 at 2:09 PM, Loui Chang wrote:

On Sun 15 Aug 2010 07:08 -0700, mike rosset wrote:

...

...

Someone unaware of dotfiles might miss them, but others (blind or sighted) should be able to access them without issue.

And all of this has nothing to do with the orignal issue /usr/local. I only suggested using something in $HOME for "user" based scripts which can be anything it does not matter.

...

It only serves to deflect from why is /usr/local/{bin,sbin} not part of the default search PATH? when its a FHS standard and has always been used for custom system wide installs? Obviously a competent system administrator can add this. However does this mean we should remove /usr/bin now to? since any competent admin can add that also.

Haha. Don't be so aggressive against discussion on an issue that you brought up in the first place. We're just trying to help put things in their proper place. But yeah I agree there are too many silly tangents on this issue. So let somebody submit a patch and get it over with.

yes, i don't see any harm in just adding it and moving on... this is heading toward bikeshed; in which case i choose green. C Anthony

On 16 August 2010 15:12, mike rosset wrote:

...

Haha. Don't be so aggressive against discussion on an issue that you brought up in the first place. We're just trying to help put things in their proper place. But yeah I agree there are too many silly tangents on this issue. So let somebody submit a patch and get it over with.

Ah wasn't meant to sound aggressive.

But I haz patch! see attached.

Can also haz bug report? --> http://bugs.archlinux.org/ -- GPG/PGP ID: B42DDCAD

Am Mon, 16 Aug 2010 21:18:58 +1000 schrieb Allan McRae :

...

Can also haz bug report? --> http://bugs.archlinux.org/

FYI, there was one a while back... It was closed as won't fix.

Why? Heiko

Am 17.08.2010 00:42, schrieb Matthew Monaco:

On 08/16/2010 09:22 AM, Heiko Baums wrote:

...

Am Mon, 16 Aug 2010 21:18:58 +1000 schrieb Allan McRae:

...

...

Can also haz bug report? --> http://bugs.archlinux.org/

FYI, there was one a while back... It was closed as won't fix.

Why?

Heiko

http://bugs.archlinux.org/task/12231

Hello, this discussion reminds me to a funny discussion we had in german Arch Linux forum. It is about a little tool and ends in the following Upstream recommendation: "ALERT: Arch Linux users report that /usr/local/bin is NOT in their default system path, so they will need to put inxi in /usr/bin instead. " https://bbs.archlinux.de/viewtopic.php?id=13379 http://techpatterns.com/forums/about1133.html So the inxi users are expected to have benefit in using inxi's quite technical output, but are not expected to be able to alter the system path. Regards Stefan

On Mon, Aug 16, 2010 at 4:50 PM, Heiko Baums wrote:

Am Mon, 16 Aug 2010 18:42:55 -0400 schrieb Matthew Monaco :

...

http://bugs.archlinux.org/task/12231

I requested to re-open this bug.

Heiko

Thank you Heiko, I'll submit the patch if the task ever gets reopened. Mike

Am Sun, 15 Aug 2010 06:19:24 -0700 schrieb mike rosset :

I agree with this /usr/local/ is a pretty common location to install system wide software and imo /usr/local/bin /usr/local/sbin should be included in the default path. FHS covers this and GNU conf also defaults to this.

However in Judd's case I would think ~/bin would be better suited for user scripts unless he needs to use them system wide ie. as another user. since its much easier to edit save the files and does not require root privileges to modify

You're not quite right. Both /usr and /usr/local are system wide, but /usr is for packages which are installed by a package manager and /usr/local is for self written user scripts. It's just that user scripts can't be overwritten by a package. Heiko

On 15 August 2010 22:14, Chris Brannon wrote:

The hand-written, system-specific scripts pose a problem, though.  Does anyone use makepkg + pacman to manage these?  Is it worth the extra effort?

I keep /usr/local for random from-the-web stuff. For my own stuff, I have ~/.bin which is a symlink to another drive independent of the system. -- GPG/PGP ID: B42DDCAD