Please add ~/.local/bin to the default $PATH

Bug #1588562 reported by Nathaniel Smith
78
This bug affects 17 people
Affects Status Importance Assigned to Milestone
bash (Debian)
Fix Released
Unknown
bash (Ubuntu)
Fix Released
Medium
Matthias Klose
Xenial
Fix Released
Medium
Unassigned

Bug Description

Starting in Xenial, 'pip install' by default places executables into ~/.local/bin. This is the de-facto standard place to put per-user executables -- for example, Fedora/Redhat puts it on the $PATH by default, and PEP 370 makes it the standard place for unprivileged installs of Python packages to put their scripts.

But unfortunately, Ubuntu's does *not* add this directory to $PATH by default, which means that 'pip install' doesn't actually work -- any scripts that are installed are inaccessible, and every user has to manually add this to their PATH.

Ubuntu should put ~/.local/bin onto PATH by default.

Minor details (discussed with @doko at the PyCon sprints):

- this should go at the beginning of PATH rather than the end, in accordance with Debian policy saying that more-local paths go before more-upstream paths. (This is inconsistent with how Fedora/RH do it, but consistent with how Python itself searches for packages.)
- this will be added to /etc/skel/profile, so that it won't change any existing user accounts; it will only be applied to user accounts created *after* this change lands
- unlike ~/bin (which Debian/Ubuntu have supported for ages), it will be added to PATH unconditionally, even if the directory doesn't exist. This is important to avoid a nasty trap for new users, where the first time they try to install a Python package they have to restart their shell. Since this only applies to new accounts, the directory will always start out nonexistent/empty, so having it in $PATH won't cause any unexpected changes in behavior.
- possibly it would make sense to set this in /etc/environment or /etc/skel/.gnomerc or similar, so that it would also apply to non-shell processes (e.g. if the user wants to add a global key-binding to launch a Python program, then generally ~/.profile *doesn't* affect the environment where this command gets executed, and that can frustrate and confuse users if a command works fine from the terminal but not from a keybinding). But we should defer this discussion for the future, because even if this is a good idea, it isn't a good idea in a Xenial stable update.

Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820856

Changed in bash (Debian):
status: Unknown → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bash (Ubuntu Xenial):
status: New → Confirmed
Changed in bash (Ubuntu):
status: New → Confirmed
Changed in bash (Debian):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bash - 4.3-15ubuntu1

---------------
bash (4.3-15ubuntu1) yakkety; urgency=medium

  * Merge with Debian; remaining changes:
    - skel.bashrc:
      - Run lesspipe.
      - Enable ls aliases.
      - Set options in ll alias to -alF.
      - Define an alert alias.
      - Enabled colored grep aliases.
    - etc.bash.bashrc:
      - Add sudo hint.

bash (4.3-15) unstable; urgency=medium

  * Apply upstream patches 043 - 046. Fixes:
    - When the lastpipe option is enabled, the last component can contain
      nested pipelines and cause a segmentation fault under
      certain circumestances.
    - A typo prevents the `compat42' shopt option from working as intended.
    - If a file open attempted as part of a redirection fails because it is
      interrupted by a signal, the shell needs to process any pending traps
      to allow the redirection to be canceled.
    - An incorrect conversion from an indexed to associative array can result
      in a core dump.
  * Add $HOME/.local/bin to PATH, and add the user's home directories
    unconditionally to the path, so that they are available without
    a new login. Closes: #820856, LP: #1588562.

 -- Matthias Klose <email address hidden> Fri, 24 Jun 2016 09:16:03 +0200

Changed in bash (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Hello Nathaniel, or anyone else affected,

Accepted bash into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/bash/4.3-14ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in bash (Ubuntu Xenial):
status: Confirmed → Fix Committed
tags: added: verification-needed
Mathew Hodson (mhodson)
Changed in bash (Ubuntu Xenial):
importance: Undecided → Medium
Changed in bash (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bash - 4.3-14ubuntu1.1

---------------
bash (4.3-14ubuntu1.1) xenial-proposed; urgency=medium

  * SRU: LP: #1595869.
  * Apply upstream patches 043 - 046. Fixes:
    - When the lastpipe option is enabled, the last component can contain
      nested pipelines and cause a segmentation fault under
      certain circumstances.
    - A typo prevents the `compat42' shopt option from working as intended.
    - If a file open attempted as part of a redirection fails because it is
      interrupted by a signal, the shell needs to process any pending traps
      to allow the redirection to be canceled.
    - An incorrect conversion from an indexed to associative array can result
      in a core dump.
  * Add $HOME/.local/bin to PATH, and add the user's home directories
    unconditionally to the path, so that they are available without
    a new login. Closes: #820856, LP: #1588562.

 -- Matthias Klose <email address hidden> Fri, 24 Jun 2016 10:20:17 +0200

Changed in bash (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Edwin Khoo (edwinksl) wrote :

Looks like this patch didn't make it to Ubuntu 17.04?

Revision history for this message
gdahlman (gdahlman) wrote :

It looks like this is fixed on 16.04 but not on 17.04/10 Most likely this was a regression when they moved to bash 4.4.

I will file a new bug and try to submit a patch.

Revision history for this message
gdahlman (gdahlman) wrote :
Revision history for this message
Edwin Khoo (edwinksl) wrote :

Very much appreciated. Subscribed to the bug report you made.

Revision history for this message
Adam Conrad (adconrad) wrote :
Revision history for this message
Steve Langasek (vorlon) wrote :

This was landed in a xenial SRU and fixed in yakkety, but the change appears to have silently fallen out of zesty and later in a Debian merge.

If this is a deliberate change because .local/bin is no longer needed in zesty and later, feel free to re-close this bug. Please also check whether the path change on xenial should be reverted.

Changed in bash (Ubuntu):
assignee: nobody → Matthias Klose (doko)
status: Fix Released → Triaged
Revision history for this message
gdahlman (gdahlman) wrote :

I very much doubt that this is a deliberate change as it is a part of the systemd file hierarchy.

It is documented in: file-hierarchy(7) linked to here: https://www.freedesktop.org/software/systemd/man/file-hierarchy.html

If the change was intentional for some reason a bug will need to be filed against the systemd package. as anything that depends on the following command will also have issues.

systemd-path user-binaries

Revision history for this message
Matthias Klose (doko) wrote :

fixed in 4.4.18-1ubuntu1

Changed in bash (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Nathaniel Smith (njs) wrote :

@doko: This still needs to be re-fixed in Debian, right?

Revision history for this message
Adrian Wilkins (adrian-wilkins) wrote :

This bug seems to be back ; noticed today when my shell can't find `packer` or any of the other lovely devops tools that have no packages and are just monolithic blobs I download to `~/.local/bin`

For now I'll fix it by adding

    export PATH="$(systemd-path user-binaries):$PATH"

to my .bashrc file...

Revision history for this message
Mark Barsky (push-uni) wrote :

Bug is stille present in Ubuntu 18.04 LTS.

Above mentioned fix does help.

Should it be reopened?

Revision history for this message
Vortex (v4vortex) wrote :

I can also confirm this Bug for Ubuntu MATE 18.04 LTS.

The fix in comment #15 does help.

Revision history for this message
Evren Yurtesen (eyurtese-g) wrote :

Add the fix on post #15 to file .bash_profile

Revision history for this message
Taddeo Manzi (sinistristradali) wrote :

This kind of behaviour (letting pass three years and still not fixing this silly to adhere to a known and used standard) is the exact reason I stopped advicing Ubuntu to people.
Because it is the exact thing that let people say "this shitty GNU/Linux you adviced me does never work! It took me 5 minutes to start noticing bugs!".
It still happens in Ubuntu 19.10.

Revision history for this message
klogg (joculator-gmail) wrote :

Bug persists in xubuntu 20.04 - checked with fresh install today:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04 LTS
Release: 20.04
Codename: focal

$ bash --version
GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu)

must be reopened

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.