On Fri, Jun 22, 2018 at 07:24:54PM +0200, Björn Persson wrote:
Till Maas wrote:
> I do not see any reason why a user would put something in ~/bin that
> would mask something in /usr/bin except to actually mask the binary. It
> is the same with other user configuration, anyone expects ~/.ssh/config
> to override /etc/ssh/ssh_config instead of the other way round.
It could happen by accident. A user might put a program in ~/bin that
happens to have the same name as one in /usr/bin that the user is
unaware of, and it might break other programs which call that command
without a full pathname. Editing ~/.ssh/config affects only SSH, and
isn't likely to break something unrelated.
That's one reason why I'm not convinced that this change is a good
idea. It obviously has nothing to do with security though. It's a
matter of safety, which is different from security.
In your opinion, how does the user act nowadays when something in
/usr/bin masks their tool that they installed in ~/bin? I would assume
that they will change the path, since installing the tool there is what
they wanted. Making it hard for users to achieve their goals usually
does not stop them. Also a tool with a same name in /usr/bin might also
break another user's tool that expects the user version to be available
in the PATH. I do not see how this would be better. And it might also
happen with aliases or functions that users would configure in
~/.bashrc. I know that bash-completion using the _* namespace broke a
lot of shortcuts that I used (and I still think it is sad that this easy
to use prefix (at least on a QWERT* keyboard) was made unusable, even
though these are identifiers nobody needs to type).
Kind regards
Till