Hi all,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
Stefan
--
Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera
On Mon, 2009-07-13 at 13:31 +0200, Stefan Assmann wrote:
Hi all,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
Stefan
Hi,
because most people don't need it? Well, I would not be exactly against making this default, but I'm not sure if $HOME/bin would be the right one... Since xdg-dirs came around I use $HOME/Applications/bin for that purpose to keep $HOME cleaner (even though this particular directory isn't in the scheme...) But I cannot really argue either way...
Martin
Hi,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
Stefan
Hi,
because most people don't need it?
True.
Look at your /etc/profile (or ~/.bash_profile, I don't remember).
There should be something like: [ -d ~/bin ] && PATH=~/bin:$PATH
Which means that the folder will be added to your PATH if it exists.
I'm on Windows XP right now, so I can't verify it, but iirc there's something like that.
----------
Mathieu Bridon (bochecha)
On Mon, 2009-07-13 at 14:07 +0200, Mathieu Bridon (bochecha) wrote:
Look at your /etc/profile (or ~/.bash_profile, I don't remember).
There should be something like: [ -d ~/bin ] && PATH=~/bin:$PATH
Which means that the folder will be added to your PATH if it exists.
Well, I have there
PATH=$PATH:$HOME/Applications/bin
and that's because I added it manually there... I don't remember the original value.
Martin
On Mon, Jul 13, 2009 at 11:47:28AM +0000, Martin Sourada wrote:
because most people don't need it? Well, I would not be exactly against making this default, but I'm not sure if $HOME/bin would be the right one... Since xdg-dirs came around I use $HOME/Applications/bin for that
Yuck!
Rich.
Stefan Assmann wrote:
Hi all,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
$HOME/bin is not on every system and the other default directories in default PATH are(at least on the most of systems ;) ). However, some Linux distros do add something as: # set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi as default - so this dir gets added automatically when does exist. I'm generally +1 for changing the default that way - as it would not change anything for users without that directory.
Greetings, Ondřej Vašík
Hey,
Am Montag, den 13.07.2009, 14:08 +0200 schrieb Ondřej Vašík:
Stefan Assmann wrote:
Hi all,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
$HOME/bin is not on every system and the other default directories in default PATH are(at least on the most of systems ;) ). However, some Linux distros do add something as: # set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi
Adding something like this raises security concerns, as this opens doors for malicious software. E.g. some application could but a binary named "bash" in ~/bin, which would be run before /bin/bash. So, if at all, let's use $PATH:$HOME/PATH
- fabian
as default - so this dir gets added automatically when does exist. I'm generally +1 for changing the default that way - as it would not change anything for users without that directory.
Greetings, Ondřej Vašík -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, Jul 13, 2009 at 02:15:12PM +0200, Fabian Deutsch wrote:
Adding something like this raises security concerns, as this opens doors for malicious software. E.g. some application could but a binary named "bash" in ~/bin, which would be run before /bin/bash.
The same application could overwrite .bash_profile too. Or it would be very contrived to imagine a security hole that lets you create ~/bin and place an arbitrary binary into ~/bin/bash, but doesn't let you overwrite .bash_profile. So I don't think this is a security concern at all in the real world.
Rich.
On Mon, Jul 13, 2009 at 10:48:35PM +0100, Richard W.M. Jones wrote:
The same application could overwrite .bash_profile too. Or it would be very contrived to imagine a security hole that lets you create ~/bin and place an arbitrary binary into ~/bin/bash, but doesn't let you overwrite .bash_profile. So I don't think this is a security concern at all in the real world.
Realistically, the concern is more likely to be binaries accidently causing subtle breakage by colliding with the expected behaviour of system utilities.
On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ondřej Vašík wrote:
Stefan Assmann wrote:
Hi all,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
$HOME/bin is not on every system and the other default directories in default PATH are(at least on the most of systems ;) ). However, some Linux distros do add something as: # set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi as default - so this dir gets added automatically when does exist. I'm generally +1 for changing the default that way - as it would not change anything for users without that directory.
I would only want this at the *end* of the current PATH, not the beginning, for obvious security reasons.
Paul W. Frields wrote:
On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ondřej Vašík wrote:
Stefan Assmann wrote:
Hi all,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
$HOME/bin is not on every system and the other default directories in default PATH are(at least on the most of systems ;) ). However, some Linux distros do add something as: # set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi as default - so this dir gets added automatically when does exist. I'm generally +1 for changing the default that way - as it would not change anything for users without that directory.
I would only want this at the *end* of the current PATH, not the beginning, for obvious security reasons.
1. Your practice to a wide extend defeats one prime rationale for ~/bin: Replacing/Overriding vendor-provided applications by per-user installed versions.
2. Unless using ~/bin as root, these files are user-installed binaries, which under normal circumstances may only have security impacts on user files => What you call "obvious security reasons" are minor concerns.
The only real issue you are solving by appending ~/bin instead of prepending ~/bin to $PATH is avoiding application-name conflicts.
Paul W. Frields wrote:
On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ondřej Vašík wrote:
Stefan Assmann wrote:
Hi all,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
$HOME/bin is not on every system and the other default directories in default PATH are(at least on the most of systems ;) ). However, some Linux distros do add something as: # set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi as default - so this dir gets added automatically when does exist. I'm generally +1 for changing the default that way - as it would not change anything for users without that directory.
I would only want this at the *end* of the current PATH, not the beginning, for obvious security reasons.
- Your practice to a wide extend defeats one prime rationale for ~/bin:
Replacing/Overriding vendor-provided applications by per-user installed versions.
- Unless using ~/bin as root, these files are user-installed binaries,
which under normal circumstances may only have security impacts on user files => What you call "obvious security reasons" are minor concerns.
if "su" (instead of "su -") is used, root will inherit user's environment including PATH.
The only real issue you are solving by appending ~/bin instead of prepending ~/bin to $PATH is avoiding application-name conflicts.
Michal Hlavinka wrote:
Paul W. Frields wrote:
On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ondřej Vašík wrote:
Stefan Assmann wrote:
Hi all,
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
$HOME/bin is not on every system and the other default directories in default PATH are(at least on the most of systems ;) ). However, some Linux distros do add something as: # set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi as default - so this dir gets added automatically when does exist. I'm generally +1 for changing the default that way - as it would not change anything for users without that directory.
I would only want this at the *end* of the current PATH, not the beginning, for obvious security reasons.
- Your practice to a wide extend defeats one prime rationale for ~/bin:
Replacing/Overriding vendor-provided applications by per-user installed versions.
- Unless using ~/bin as root, these files are user-installed binaries,
which under normal circumstances may only have security impacts on user files => What you call "obvious security reasons" are minor concerns.
if "su" (instead of "su -") is used, root will inherit user's environment including PATH.
Yes, but ... we are talking about ordinary users here, not about users who have root access. These people have other means to install packages.
For ordinary users, prepending ~/bin to $PATH is the only approach e.g. to replace vendor-supplied applications, the "security risks" are almost non-existent.
Ralf
Emmanuel Seyman wrote:
- Ralf Corsepius [13/07/2009 15:50] :
For ordinary users, prepending ~/bin to $PATH is the only approach e.g. to replace vendor-supplied applications, the "security risks" are almost non-existent.
You can also use bash aliases to override binary calls.
Sometimes, but not always.
e.g. when testing "application suites" which install many binaries.
Ralf
* Stefan Assmann [13/07/2009 13:53] :
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
[manu@orient ~]$ rpm -q fedora-release fedora-release-11-1.noarch [manu@orient ~]$ rpm -qf /etc/skel/.bash_profile bash-4.0-6.fc11.i586 [manu@orient ~]$ rpm -qV bash-4.0-6.fc11.i586 [manu@orient ~]$ grep PATH /etc/skel/.bash_profile PATH=$PATH:$HOME/bin export PATH
Emmanuel
On 13.07.2009 14:28, Emmanuel Seyman wrote:
- Stefan Assmann [13/07/2009 13:53] :
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
[manu@orient ~]$ rpm -q fedora-release fedora-release-11-1.noarch [manu@orient ~]$ rpm -qf /etc/skel/.bash_profile bash-4.0-6.fc11.i586 [manu@orient ~]$ rpm -qV bash-4.0-6.fc11.i586 [manu@orient ~]$ grep PATH /etc/skel/.bash_profile PATH=$PATH:$HOME/bin export PATH
Emmanuel
Thanks for pointing this out! .bash_profile was missing in my home directory, not sure why.
Stefan
--
Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera
Stefan Assmann sassmann@redhat.com writes:
I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default?
It should be there, but some kind of bug prevents evaluation of ~/.bash_profile (which adds this directory to $PATH).
$ echo $PATH /home/ensc/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/games
<press alt-shift-f2 -> starts the xfrun4 "Run program" application) $ ps wwwe `/sbin/pidof xfrun4` 4220 ? Ss 0:00 /usr/bin/xfrun4 --daemon ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
It's probably some kind of undebuggable d-bus interaction :( Hence, use xterm to start your applications, but not this buggy desktop crap.
Enrico
On Mon, Jul 13, 2009 at 03:54:51PM +0200, Enrico Scholz wrote:
$ echo $PATH /home/ensc/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/games
<press alt-shift-f2 -> starts the xfrun4 "Run program" application) $ ps wwwe `/sbin/pidof xfrun4` 4220 ? Ss 0:00 /usr/bin/xfrun4 --daemon ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
.bash_profile is only evaluated for login shells.
It's probably some kind of undebuggable d-bus interaction :( Hence, use xterm to start your applications, but not this buggy desktop crap.
It seems to be working as expected, given the implementation. Please don't blame parts of the software stack just because you don't understand them - it doesn't provide much incentive to improve things.
Matthew Garrett mjg@redhat.com writes:
<press alt-shift-f2 -> starts the xfrun4 "Run program" application) $ ps wwwe `/sbin/pidof xfrun4` 4220 ? Ss 0:00 /usr/bin/xfrun4 --daemon ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
.bash_profile is only evaluated for login shells.
How else is the program environment (e.g. $http_proxy or $PATH) supposed to be set for applications started by the "Run program" desktop feature?
And -- I want it to be consistent across xterm, the xfce4-panel buttons (which both have the bash profile environment) and "Run program".
It's probably some kind of undebuggable d-bus interaction :( Hence, use xterm to start your applications, but not this buggy desktop crap.
It seems to be working as expected, given the implementation.
Most computer languages guarantee that everything works as expected, given its implementation. But this does not mean that it works correctly.
Enrico