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.
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
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/....
++
Am Sun, 15 Aug 2010 11:21:24 +0200 schrieb Laurent Carlier lordheavym@gmail.com:
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
On Sun, Aug 15, 2010 at 5:44 AM, Heiko Baums lists@baums-on-web.de wrote:
Am Sun, 15 Aug 2010 11:21:24 +0200 schrieb Laurent Carlier lordheavym@gmail.com:
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
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.
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
On Sun 15 Aug 2010 06:33 -0700, mike rosset wrote:
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.
Someone unaware of dotfiles might miss them, but others (blind or sighted) should be able to access them without issue.
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 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.
On Sun, Aug 15, 2010 at 2:09 PM, Loui Chang louipc.ist@gmail.com 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
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.
Mike
On 16 August 2010 15:12, mike rosset schizoid29@gmail.com 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
On 16/08/10 21:08, Ray Rashif wrote:
On 16 August 2010 15:12, mike rossetschizoid29@gmail.com 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/
FYI, there was one a while back... It was closed as won't fix.
Allan
Am Mon, 16 Aug 2010 21:18:58 +1000 schrieb Allan McRae allan@archlinux.org:
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
On 08/16/2010 09:22 AM, Heiko Baums wrote:
Am Mon, 16 Aug 2010 21:18:58 +1000 schrieb Allan McRaeallan@archlinux.org:
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 McRaeallan@archlinux.org:
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
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
Am Mon, 16 Aug 2010 18:42:55 -0400 schrieb Matthew Monaco dgbaley27@verizon.net:
I requested to re-open this bug.
Heiko
On Mon, Aug 16, 2010 at 4:50 PM, Heiko Baums lists@baums-on-web.de wrote:
Am Mon, 16 Aug 2010 18:42:55 -0400 schrieb Matthew Monaco dgbaley27@verizon.net:
I requested to re-open this bug.
Heiko
Thank you Heiko, I'll submit the patch if the task ever gets reopened.
Mike
On 08/16/2010 07:50 PM, Heiko Baums wrote:
Am Mon, 16 Aug 2010 18:42:55 -0400 schrieb Matthew Monacodgbaley27@verizon.net:
I requested to re-open this bug.
Heiko
I didn't give the link so you could reopen it. I think the short discussion makes it clear that local will not be included in the path.
Am Sun, 15 Aug 2010 06:19:24 -0700 schrieb mike rosset schizoid29@gmail.com:
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
Jude DaShiell jdashiel@shellworld.net writes:
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 suspect that /usr/local/bin is excluded from the default $PATH to encourage good system administration habits. I.E., all of the software installed on a system should be managed by the package manager. When I used Slackware, /usr/local was the dumping ground where I placed all of the software that I built from source. It was an uncontrolled mess. I'm really ashamed to admit it. Keeping /usr/local/bin out of $PATH discourages people from using ./configure, make, make install as their package "management" procedure.
The hand-written, system-specific scripts pose a problem, though. Does anyone use makepkg + pacman to manage these? Is it worth the extra effort?
-- Chris
On 15 August 2010 22:14, Chris Brannon cmbrannon79@gmail.com 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
On Sun, 15 Aug 2010, Chris Brannon wrote:
Jude DaShiell jdashiel@shellworld.net writes:
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 suspect that /usr/local/bin is excluded from the default $PATH to encourage good system administration habits. I.E., all of the software installed on a system should be managed by the package manager. When I used Slackware, /usr/local was the dumping ground where I placed all of the software that I built from source. It was an uncontrolled mess. I'm really ashamed to admit it. Keeping /usr/local/bin out of $PATH discourages people from using ./configure, make, make install as their package "management" procedure.
The hand-written, system-specific scripts pose a problem, though. Does anyone use makepkg + pacman to manage these? Is it worth the extra effort?
-- Chris
Production systems probably don't need /usr/local/ hierarchy let alone paths to it. Development and testing systems would find them very useful for building foreign tar balls though. Use of standards enables everyone in a community to sit down at another machine and have a pretty good idea where things ought to be located and what paths ought to be set. That in itself can properly be viewed as a security check because when things just don't look right anymore on a system they may have to be restored from a backup (script kitties) may have been having fun. As for my own uses, I put development systems up because when new packages become available they're not always available for the particular Linux in use and I want to find out can these work and what needs to be done to get them working.
arch-general@lists.archlinux.org