~/.local/bin not ending up on executable path

[mungojam]

• Your Windows build number:
  Version 10.0.15063

• What you're doing and what's happening:
  I was trying to install a python pip script from here. It installs fine, but unless I use sudo pip, I can't run it directly from the console because it installs into ~/.local/bin/ which doesn't appear to be picked up as a path variable.

Steps to reproduce:

sudo apt-get install python-pip
pip install cfn_flip
cfn_flip -h

It's possible to run it fine using ~/.local/bin/cfn_flip -h

My path variable is:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files/Microsoft SQL Server/130/Tools/Binn:/mnt/c/Program Files/dotnet:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/MiKTeX 2.9/miktex/bin/x64:/mnt/c/Users/mark/Dropbox/Marks/Apps/Python36/Scripts:/mnt/c/Users/mark/Dropbox/Marks/Apps/Python36:/mnt/c/Users/mark/AppData/Local/Programs/Python/Launcher:/mnt/c/Users/mark/AppData/Local/Microsoft/WindowsApps:/mnt/c/Program Files (x86)/Microsoft VS Code/bin

• What's wrong / what should be happening instead:
  The above should be runnable and should give the standard usage instructions for the script

Looks like it is a standard path for some recent versions of ubuntu as per
this stackexchange question

[mungojam]

Looks like it was fixed in bash 4.3.15 but I have bash 4.3.48 which is later but does not have the fix.

The full version I have is:
version 4.3.48(1)-release-(x86_64-pc-linux-gnu)

[sunjoong]

@mungojam - Hmm.... You look like to say a program cfn_flip is in ~/.local/bin directory but that directory was not included in PATH enverionment; Is that right? If so, simplely....

export PATH=${HOME}/.local/bin:$PATH

Put above line to ~/.bashrc file.

REF:

• https://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux
• https://stackoverflow.com/questions/415403/whats-the-difference-between-bashrc-bash-profile-and-environment

[mungojam]

@sunjoong Thanks for the tip, I managed to get it working by re-running the pip call with sudo.

I think it should be added as a standard path since that what Ubuntu itself has done now and python/pip are a major use case for BashOnWindows which is trying to be as frictionless as possible for developers.

[sunjoong]

@mungojam - You may be right or not, but that would be an ubuntu issue, not bash on ubuntu on windows issue, I think, becasue bash on ubuntu on windows is a just name called as linux subsystem for windows (WSL); For example, I'm a gentoo linux user on WSL, not ubuntu, and ~/.local/bin is not a linux standard.

[mungojam]

@sunjoong see my comment about bash. It looks like it was fixed in an earlier version of bash. So my suspicion is that BashOnWindows alters the path in order to add the windows path, but hasn't taken the change to bash.

I'll admit I don't fully get how the WSL vs. Bash For Windows is implemented since I didn't specifically choose ubuntu, it was the default that got deployed.

Regarding the standard, you're right it isn't a standard and some linux distributions have decided not to use it. Fedora had a rather large discussion about it here, though I can't tell if they went with it or not in the end.

But since ubuntu does have it, and yet the install of ubuntu done by Windows 10 doesn't have it, it seems the issue lies with BashOnWindows somehow.

[sunjoong]

@mungojam - I said that would be a ubuntu issue and ubuntu adapted that already by appending PATH="$HOME/bin:$HOME/.local/bin:$PATH" line to ~/.profile file. So, you could be wonder why this was not applied for you, I think. Well... that's because your bash shortcut will invork bash not login mode; You could see the property of bash shortcut named Bash on Ubuntu on Windows set to "C:\Windows\System32\bash.exe ~".

I heard next (or next after next) version will provide login mode as default, but you could do it now by appending option like "C:\Windows\System32\bash.exe ~ -l"; And about option -l, you could think it as -l of login.

[mungojam]

You're right, it is set in .profile which isn't then used. I've now been reading up a lot on login mode which I didn't know about previously so thank you for bearing with me and identifying the issue.

With 'C:\Windows\System32\bash.exe ~ -l' I did indeed get it in the path.

I've found issue #816 regarding the change you mention. Looks like it is changed in current development build so hopefully that will filter through at some point.

Your workarounds are very handy in the time being and I've learnt some things, so thanks :).

[mungojam]

I thought this might have been fixed in Fall Creator's Update, but it doesn't seem to have been. I've tried my original steps in Ubuntu and it still doesn't work, since presumably it is still not a login shell by default?

[mungojam]

My mistake, sorry. Ran cfn_flip (the package name) rather than cfn-flip. It's all working fine