I did
brew install python3
when i run python --version it shows 2.7
Document says:
If you still see 2.7 ensure in PATH /usr/local/bin/ takes precedence over /usr/bin/
How do I go about this?
First, you'll want to verify the problem is as stated.
Try running e.g.
> echo $PATH
/usr/local/bin:/Users/jsh/code/go/bin:/usr/bin:/bin:/usr/local/sbin:/usr/texbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
You'll notice that the output is a series of paths separated by ':' characters. Your terminal looks in those locations, in order, until it finds something that matches your command (in this case 'python') and it runs that binary.
This means that earlier items take precedence over later items. You'll note that in my listing, /usr/local/bin/ is at the very beginning, and /usr/bin/ is somewhat later in the listing.
If your listing also has this ordering, you're getting a misleading message, and will need to dig deeper. Hopefully, however, you will find that either /usr/local/bin/ isn't in your list at all, or it is for some reason occurring after /usr/bin/. That's good -- you've now identified the problem -- and we're now at your nominal question, vis: how do you change the ordering?
The environment variable $PATH can be modified by any number of startup tools. There are probably ways to systematically observe all the things that are editing your $PATH, but what I would do is
1) Search in your home directory for things that might be messing with $PATH, something like:
> egrep -d skip -l PATH .*
.gvimrc
.zhistory
.zshrc
.zhistory, here, is a red herring -- it's a list of the stuff I've done in my shell, so I can ignore it.
.gvimrc is also misleading, because it's actually setting $GOPATH, not $PATH.
So the only configuration file I have messing with my $PATH, at least in my home directory, is .zshrc, the config file for my shell itself. This is typically true, and you can just start by assuming this, but it's always good to do a quick search...
2) Edit the responsible file until it is setting PATH so that /usr/bin/local/ precedes /usr/bin/. Open the file in your choice of editor and either modify the line that sets PATH, or add a line that prepends /usr/local/bin/ to PATH (if you go with the latter, make sure that prepend happens after all other modifications to the variable).
For example, my .zshrc has a block like this:
# PATH setup (Starting with hard reset)
export PATH=/sbin
export PATH=/usr/sbin:$PATH
export PATH=/usr/texbin:$PATH
export PATH=/usr/local/sbin:$PATH
export PATH=/bin:$PATH
export PATH=/usr/bin:$PATH
export PATH=/Users/jsh/code/go/bin:$PATH
export PATH=/usr/local/bin:$PATH
(Note that the FINAL LINE is the one prepending /usr/local/bin !)
Then restart your shell (or prompt it to reload the config file, but I'm betting if you knew how to do that, you wouldn't have needed this guidance!). Now re-run 'echo $PATH', and verify that the ordering is correct. If so, try running python again, and you should have an uncle named Bob.
Good luck!
Related
I've installed Anaconda and have added the environment variable export PATH="~/anaconda/bin:$PATH" to my .zshrc but still can't run any 'conda' commands in my terminal. I have followed these commands(source) to install anaconda.
# Go to home directory
cd ~
# You can change what anaconda version you want at
# https://repo.continuum.io/archive/
wget https://repo.continuum.io/archive/Anaconda3-4.2.0-Linux-x86_64.sh
zsh Anaconda3-4.2.0-Linux-x86_64.sh -b -p ~/anaconda
rm Anaconda3-4.2.0-Linux-x86_64.sh
echo 'export PATH="~/anaconda/bin:$PATH"' >> ~/.zshrc
# Refresh basically
source ~/.zshrc
Am I missing anything?
This kind of issue often arise due to incorrect paths to your Python distribution. Basically, your computer does not know where to look for the correct file or program and you need to tell it where to look using your system's $PATH variable. You will thus need to manually set the paths by editing your .profile or .rc file. The most commonly used shell is bash. Both Anaconda and Canopy assume you're running the Bash shell and will put the path to your install there.
The steps below worked for me on Mac, it should work on Linux as well:
1. Go to your home directory by typing cd ~ from the prompt, or by open that same directory in Finder.
2. Now get a list of all the files in this folder, including the hidden ones:
ls -la
or, directly in Finder (without the "+"):
CMD + SHIFT + .
Now, you probably have (a) both the .profile and .bash_profile, or (b) just one of them, or (c) none of them:
3.a If you are using Bash, you're looking for files called .profile and .bash_profile. Which you have will depend on your system configuration. If you have both, this is probably the root cause of your problem; .bash_profile overrides .profile if both are present. In this case, open .profile and copy everything you find inside across to .bash_profile.
3.b If you only have one of .bash_profile or .profile, open it in an editor and have a look. You're looking for any obvious references to Python or your distribution (Anaconda, Canopy) on any of the uncommented-out lines. You'll probably see several lines that look something like:
PATH="Users/<your user name>/Library/...:${PATH}"
export PATH
In the rare case that you don't see any reference to Anaconda at all, you will need to add the lines yourself. Add, for example, the following to the file:
export PATH=~/anaconda/bin:$PATH
3.c If it turns out that you don't have any of the files, you would have to create one by yourself. Do this by entering touch .bash_profile in the prompt, or, simply right click and create a new file directly in Finder. Add the following to the file (same as in (b)):
export PATH=~/anaconda/bin:$PATH
4. Save the file. Quit and restart any program that use Python (including the Terminal window), and you should be good to go.
More detailed info here (including for Windows):
https://github.com/landlab/landlab/wiki/Correcting-Install-Paths
How do I change it, so executable files don't have another color, compared to other files? I'm on macOS Sierra (10.12.6). It's the same, both in the regular Terminal:
... or in iTerm2:
It's frustating to look at. If i write chmod -x [FILENAME] then it disappears. But I don't want to change if the files are executable or not, - I want to change the color of executable files. I want my files to look like this (regardless of if it's executable or not):
I tried correcting Anshuman's answer, so it could help people with the potential same challenges. His answer pointed me in the right direction, but was pretty far from the answer to the question. So I'll post it here myself.
The LSCOLORS are set in your ~/.bash_profile (or ~/.zshrc-file, if you use Zshell) for your environment. On this page, then you can experiment a bit with the settings and see which letters changes which colors. It's in your current LSCOLORS that it's setting the color of your executable files to be another color. Here's how you find (and change) that color:
Go to your terminal and write:
echo $LSCOLORS
then it'll print out your current setup, which might be something along these lines:
Gxfxcxdxbxegedabagacad
If you then (in this case) change it to this:
GxfxcxdxDxegedabagacad
Then it would change the colors of the executable files. And what that change comes down to, is which color in your profile, it's pointing to:
set the LSCOLORS environment variable
create an alias for ls so that it shows colors by default
In your ~/.bash_profile add the following:
export LSCOLORS="EHfxcxdxBxegecabagacad"
alias ls='ls -lGH' <-----This shows in list format, follow symlinks colorized
Another way to handle this problem is to simply override "ls --color" altogether, I recently solved this problem with a simple awk script and shell wrapper called "cf".
Then you can create alias for ls like this:
alias ls='_(){ /bin/ls -F -1 -A "$#"|cf|column;};_'
See screenshots and get it from: GitHub
It also has a deb installer
To leave the system in a cleaner state, I am trying to remove entries from the PATH in the %preun section of my rpm spec file.
I found couple of threads on stackoverflow that I tried
What is the most elegant way to remove a path from the $PATH variable in Bash?
AND
Linux: Remove path from $PATH variable
Answers in both these links work perfectly when I manually run them on a terminal.
But, they don't work when I run the rpm -e xx command.
If my PATH looked like this after successful installation:
/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/lpp/mmfs/bin
and I am trying to remove /usr/lpp/mmfs/bin,
After the rpm uninstall the PATH looks like:
/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin
Questions:
1) Do I need to do something different when the commands mentioned in the earlier links are run from the spec file?
2) What are some recommended ways to remove PATH entries during rpm uninstalls?
Note
Commands I have tried in spec file are:
PATH=$(echo $PATH | sed -e 's;:\?/home/user/bin;;' -e 's;/home/user/bin:\?;;')
and
PATH=${PATH/:\/home\/user\/bin/}
The RPM %preun script cannot affect the PATH variable of any running shells. That isn't possible.
It can't (directly) affect the PATH variable of any new shells either.
The only thing it can do is remove whatever changes it made to the system (or user shudder) shell startup files that caused the PATH variable additions to be made.
Removing those changes will cause any new shells not to have those changes made and therefore not to have those additional PATH entries in them.
The proper way of adding to a PATH (and subsequently, removing it later), would be to drop a file yourpackage.sh and yourpackage.csh in /etc/profile.d.
I also agree with others that it's probably a bad idea, but if you need to do it, that's how I would.
I want to add a small script to the linux PATH so I don't have to actually run it where it's physically placed on disk.
The script is quite simple is about giving apt-get access through a proxy I made it like this:
#!/bin/bash
array=( $# )
len=${#array[#]}
_args=${array[#]:1:$len}
sudo http_proxy="http://user:password#server:port" apt-get $_args
Then I saved this as apt-proxy.sh, set it to +x (chmod) and everything is working fine when I am in the directory where this file is placed.
My question is : how to add this apt-proxy to PATH so I can actually call it as if it where the real apt-get ? [from anywhere]
Looking for command line only solutions, if you know how to do by GUI its nice, but not what I am looking for.
Try this:
Save the script as apt-proxy (without the .sh extension) in some directory, like ~/bin.
Add ~/bin to your PATH, typing export PATH=$PATH:~/bin
If you need it permanently, add that last line in your ~/.bashrc. If you're using zsh, then add it to ~/.zshrc instead.
Then you can just run apt-proxy with your arguments and it will run anywhere.
Note that if you export the PATH variable in a specific window it won't update in other bash instances.
You want to define that directory to the path variable, not the actual binary e.g.
PATH=$MYDIR:$PATH
where MYDIR is defined as the directory containing your binary e.g.
PATH=/Users/username/bin:$PATH
You should put this in your startup script e.g. .bashrc such that it runs each time a shell process is invoked.
Note that order is important, and the PATH is evaluated such that if a script matching your name is found in an earlier entry in the path variable, then that's the one you'll execute. So you could name your script as apt-get and put it earlier in the path. I wouldn't do that since it's confusing. You may want to investigate shell aliases instead.
I note also that you say it works fine from your current directory. If by that you mean you have the current directory in your path (.) then that's a potential security risk. Someone could put some trojan variant of a common utility (e.g. ls) in a directory, then get you to cd to that directory and run it inadvertently.
As a final step, after following the solution form proposed by #jlhonora (https://stackoverflow.com/a/20054809/6311511), change the permissions of the files in the folder "~/bin". You can use this:
chmod -R 755 ~/bin
make an alias to the executable into the ~/.bash_profile file and then use it from anywhere or you can source the directory containing the executables you need run from anywhere and that will do the trick for you.
adding to #jlhonora
your changes in ~./bashrc or ~./zshrc won't reflect until you do
source ~./zshrc or source ./bashrc , or restart your pc
I have a file called x.sh that I want to execute. If I run:
x.sh
then I get:
x.sh: command not found
If I run:
./x.sh
then it runs correctly. Why do I have to type in ./ first?
Because the current directory is not into the PATH environment variable by default, and executables without a path qualification are searched only inside the directory specified by PATH. You can change this behavior by adding . to the end of PATH, but it's not common practice, you'll just get used to this UNIXism.
The idea behind this is that, if executables were searched first inside the current directory, a malicious user could put inside his home directory an executable named e.g. ls or grep or some other commonly used command, tricking the administrator to use it, maybe with superuser powers. On the other hand, this problem is not much felt if you put . at the end of PATH, since in that case the system directories are searched first.
But: our malicious user could still create his dangerous scripts named as common typos of often used commands, e.g. sl for ls (protip: bind it to Steam Locomotive and you won't be tricked anyway :D).
So you see that it's still better to be safe that, if you type an executable name without a path qualification, you are sure you're running something from system directories (and thus supposedly safe).
Because the current directory is normally not included in the default PATH, for security reasons: by NOT looking in the current directory all kinds of nastiness that could be caused by planting a malicious program with the name of a legitimate utility can be avoided. As an example, imagine someone manages to plant a script called ls in your directory, and that script executes rm *.
If you wish to include the current directory in your path, and you're using bash as your default shell, you can add the path via your ~/.bashrc file.
export PATH=$PATH:.
Based on the explanation above, the risk posed by rogue programs is reduced by looking in . last, so all well known legitimate programs will be found before . is checked.
You could also modify the systemwide settings via /etc/profile but that's probably not a good idea.
Because current directory is not in PATH (unlike cmd in Windows). It is a security feature so that malicious scripts in your current directory are not accidentally run.
Though it is not advisable, to satisfy curiosity, you can add . to the PATH and then you will see that x.sh will work.
If you don't explicitly specify a directory then the shell searches through the directories listed in your $PATH for the named executable. If your $PATH does not include . then the current directory is not searched.
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
This is on purpose. If the current directory were searched then the command you type could potentially change based on what directory you're in. This would allow a malicious user to place a binary named ls or cp into directories you frequent and trick you into running a different program.
$ cat /tmp/ls
rm -rf ~/*
$ cd /tmp
$ ls
*kaboom*
I strongly recommend you not add . to your $PATH. You will quickly get used to typing ./, it's no big deal.
You can't execute your file by typing simply
x.sh
because the present working directory isn't in your $PATH. To see your present working directory, type
$ pwd
To see your $PATH, type
$ echo $PATH
To add the current directory to your $PATH for this session, type
$ PATH=$PATH:.
To add it permanently, edit the file .profile in your home directory.