Created attachment 1475357 [details] journal Description of problem: According https://fedoraproject.org/wiki/Changes/UserPathPrioritization, ~/.local/bin should be moved to the top of the PATH which means there is no need to export PATH=$PATH:$HOME/.local/bin/. [test@localhost cockpit-auto]$ pip install pipenv --user Collecting pipenv ... The scripts pewtwo, pipenv and pipenv-resolver are installed in '/home/test/.local/bin' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location. Successfully installed pipenv-2018.7.1 [test@localhost cockpit-auto]$ pipenv install bash: pipenv: command not found [test@localhost cockpit-auto]$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin [test@localhost cockpit-auto]$ export PATH=$PATH:$HOME/.local/bin/ [test@localhost cockpit-auto]$ pipenv Usage: pipenv [OPTIONS] COMMAND [ARGS]... Version-Release number of selected component (if applicable): Fedora-Server-dvd-x86_64-Rawhide-20180807.n.1.iso bash-4.4.23-3.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
What is $PATH set to in your ~/.bash_profile ? The issue you mentioned in description was fixed by modifying default .bash_profile that is created for new users, so unless you are doing a fresh installation you will have to update it manually.
This is a little weird, PATH=$HOME/.local/bin:$HOME/bin:$PATH is in ~/.bash_profile,but "pip install pipenv --user" command claims that: The script virtualenv is installed in '/home/lnie/.local/bin' which is not on PATH I reproduce this on a fresh installed VM with Fedora-Server-dvd-x86_64-Rawhide-20180807.n.1.iso [lnie@localhost ~]$ pip install pipenv --user Collecting pipenv Downloading https://files.pythonhosted.org/packages/de/17/f00322241d0ec714e7c63b5e05c6c37fcc266e38c16ebcab4f5d1aee3761/pipenv-2018.7.1-py2-none-any.whl (5.0MB) 100% |████████████████████████████████| 5.0MB 1.3MB/s Collecting certifi (from pipenv) Downloading https://files.pythonhosted.org/packages/16/1f/50d729c104b21c1042aa51560da6141d1cab476ba7015d92b2111c8db841/certifi-2018.8.13-py2.py3-none-any.whl (146kB) 100% |████████████████████████████████| 153kB 2.6MB/s Requirement already satisfied: setuptools>=36.2.1 in /usr/lib/python2.7/site-packages (from pipenv) (39.2.0) Requirement already satisfied: pip>=9.0.1 in /usr/lib/python2.7/site-packages (from pipenv) (18.0) Collecting virtualenv (from pipenv) Downloading https://files.pythonhosted.org/packages/b6/30/96a02b2287098b23b875bc8c2f58071c35d2efe84f747b64d523721dc2b5/virtualenv-16.0.0-py2.py3-none-any.whl (1.9MB) 100% |████████████████████████████████| 1.9MB 2.3MB/s Collecting virtualenv-clone>=0.2.5 (from pipenv) Downloading https://files.pythonhosted.org/packages/6d/c2/dccb5ccf599e0c5d1eea6acbd058af7a71384f9740179db67a9182a24798/virtualenv_clone-0.3.0-py2.py3-none-any.whl Installing collected packages: certifi, virtualenv, virtualenv-clone, pipenv The script virtualenv is installed in '/home/lnie/.local/bin' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location. The script virtualenv-clone is installed in '/home/lnie/.local/bin' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location. The scripts pewtwo, pipenv and pipenv-resolver are installed in '/home/lnie/.local/bin' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location. Successfully installed certifi-2018.8.13 pipenv-2018.7.1 virtualenv-16.0.0 virtualenv-clone-0.3.0 [lnie@localhost ~]$ cat .bash_profile # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=$HOME/.local/bin:$HOME/bin:$PATH export PATH [lnie@localhost ~]$ pipenv bash: pipenv: command not found
Created attachment 1475744 [details] journal
What is the output of 'echo $PATH' ?
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
(In reply to Siteshwar Vashisht from comment #4) > What is the output of 'echo $PATH' ? The same as mentioned in comment#0 [lnie@localhost ~]$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
So it looks like you are running a non-login shell and ~/.bash_profile is not sourced in non-login shells. I am checking if the line which sets $PATH can be moved under .bashrc.
https://src.fedoraproject.org/rpms/bash/pull-request/9
Looks good to me. Minor comments inline...
bash-4.4.23-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-137bd2ceda
Seems still doesn't work. Run the command directly in the test machine you get [lnie@localhost ~]$ echo $PATH /usr/share/Modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin While,if you ssh to the test machine and run the same command,you will get [lnie@localhost ~]$ echo $PATH /usr/share/Modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
What is the version of bash you are using ? Also, with the updated package, you need to create a new user to see this change.
Exactly, an update of bash will not change anything in your home directory. You need to merge the changes from /etc/skel/.bash* to ~/.bash* yourself.
bash-4.4.23-4.fc29,that's for sure...and it works after I create a new user.
bash-4.4.23-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-137bd2ceda
bash-4.4.23-4.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
In the fresh installed system with Fedora-Workstation-Live x86_64-29-20180923.n.0.iso you will see [lnie@localhost ~]$ echo $PATH /home/lnie/.local/bin:/home/lnie/bin:/home/lnie/.local/bin:/home/lnie/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin If you ssh into that system,the thing is fine: [root@localhost lnie]# echo $PATH /home/lnie/.local/bin:/home/lnie/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
I recently realised that we may want to also have the same behavior even for non login shells, like services. I can explain why by giving a real world example: jenkins, which runs as a service. Very often running jenkins builds require additional tools like cmake, nodejs, ... which need to be available to jenkins service user. In some cases versions of these tools may conflict with operating system ones and thus is better (and safer) to install them to the user bin folder. Historically I manually had to alter PATH (order) to assure these tools are found or that the right version is used. If we would provide a default setting that assures that user bin is in user PATH for all accounts (user and service), we could ease deployment of new services. This would a huge benefit for those deploying python (probably node, ruby,... too) based services because they could simply install their dependencies at (service) user level and consume them, without the need to create and activate virtual environments, or to alter the PATH.
The real bug was: he should have been running a login shell or a child process of a login shell. Then his PATH environment variable would have been set correctly. That's the problem that should have been fixed; not defining and exporting the PATH environment variable from .bashrc. "The right place to define environment variables such as PATH is ~/.profile (or ~/.bash_profile if you don't care about shells other than bash)." -- https://unix.stackexchange.com/a/26059/89782 The solution chosen for this bug muddies the difference between .bashrc and .bash_profile, and login shells and non-login shells.
Additionally, moving the PATH customization to .bashrc will cause problems for those who, like myself, follow the best practice of only including .bashrc if the shell is interactive: """ include ~/.bashrc if the shell is interactive ... case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac -- https://superuser.com/a/183980 """ Followers of this best practice will be surprised when the their non-interactive shells do not have their PATH customization in affect. E.g., Alt+F2 will not find executables in ~/bin or ~/.local/bin.
The underlying problem is that Fedora builds bash with `#define NON_INTERACTIVE_LOGIN_SHELLS`, which causes certain files to be sourced even for non-interactive login shells.
Root cause of this bug is a Cockpit bug: https://github.com/cockpit-project/cockpit/issues/12803 Fedora should return to best practices for bash start-up files. PATH customizations should be done in .bash_profile.
Which best practices do you refer to?