$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 15:05, Christopher wrote:
> On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas <leamas.alec at gmail.com> wrote:
>> On 2013-10-30 11:23, Reindl Harald wrote:
>>> Am 30.10.2013 11:20, schrieb Alec Leamas:
>>>> On 2013-10-30 10:58, Reindl Harald wrote:
>>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
>>>>>> Some kind of reference for the bad in having a well-known, hidden
>>>>>> directory in the path?
>>>>> the *writeable for the user* is the problem
>>>> Any reference for this problem?
>>> what about consider the implications?
>>> do you really need a written reference for any security relevant fact?
>>> i can write one for you if you prefer links :-)
>>>
>> Well, the question is really if someone else out there share your concerns
>> about this.
> I share them, and I agree that it is the argument, not a citation,
> that demonstrates the merits of the security case.
>
> Supporting user-installed software in $HOME is a fine goal... but it
> shouldn't be done in a way that puts user-installed software earlier
> in the path by default, or expanding the number of points for users to
> watch for bad-behaving apps. As a long-time user of Fedora, I'd have
> never even thought of checking for executables in ~/.local/bin, until
> I happened to read this thread... and when I did, it was quite
> unnerving.
>
> The one reprieve from all this, is that, when I checked, it was later
> in the path than the system paths (at least for me), not earlier, as
> was previously asserted in this thread.
Yup, same for me, it's after the system paths. Which is fine, 
user-installed sw should not override system's by default.
> [cut]
>
> And, the xdg argument doesn't seem like a sufficient argument for
> me... we're talking about login scripts, not X. It is very unintuitive
> that an xdg-related directory would be on the default path for a bash
> login, if you're not even running X. This is a bash profile... not an
> X profile...
Still, actual usecases such as pip install are not limited to GUI 
programs. IMHO, the need for user installs together with the already 
established ~/.local/share makes it natural to use ~/.local as an 
installation prefix. Which implies  ~/.local/bin and also ~/.local/lib 
in the long run. Why should this just apply to GUI programs?
> The biggest problem isn't that it's hidden or that it's there by
> default, or that it's writable by potentially bad-behaving software.
> The biggest problem is simply that users don't know about it. I
> certainly didn't.
Agreed, this is the problem. However, to me it  seems better to use a 
consistent solution based on ~/.local rather than having each 
user-installed non-rpm package create it's own idea of a bin directory,  
possibly fiddling witg $PATH to make it work. Yes, it takes some time to 
learn - but isn't it actually easier in the long run?

--alec