I have used export before but I don't know why when I set the variable PATH to any directory this time, ls, awk commands are not found but no problem with pwd, cd
export PATH="/Users/carolW/Desktop"
ls
-sh: ls: command not found
Use:
export PATH=/Users/carolW/Desktop:$PATH
You're removing all the normal directories from your path, so it only looks in your Desktop folder for everything. You just want to add your directory, not replace the entire path with it.
most probably because pwd and cd are built shell command
(you can test:
which pwd
which ls
)
However, ls are such are tools you can find in /bin directory or such, and those paths are defined in your variable PATH.
If you clear the variable PATH, most likely you won't find your tool anymore.
You may use export PATH=$PATH:"/Users/carolW/Desktop"
So that you concatenate your path to the already existing paths
Related
I am using an ssh account that connects to an external server, i have downloaded through guix some software like samtools and bedtools but when i try to use them in my directory it gives me this error:
-bash: samtools: command not found
In my direcory, however, there is the directry guix.profile and if I go into the bin folder of this, I have everything I downloaded.
What am I doing wrong?
Thank you
enter image description here
To run a file from the shell you need two things:
The shell must find the file
Being in the same directory does not enable the shell to find the file. You have to either supply an absolute or relative path the file, or have the directory in your PATH environment variable
In simplest terms this means instead of
$ samtools
try
$ ./samtools
The relative path tells the shell it wants that file
To run it from another directory, either use the whole absolute path, e.g. /home/yourname/samtools , or move the file into a directory that is on your $PATH
The file needs to be executable
If the file is not executable you will need
$ chmod +x ./samtools
I'm trying to put all my symlinks in one directory (I'll call this symlinks directory). I've exported the path of that directory and put it in my .bashrc file. The symlinks to executable applications are running fine but I'm having hard time making symlinks for my directory. This is what I tried.
ln -s ~/mydir/ m
where m is supposed to be my symlink to mydir directory.
This works only when I'm inside symlinks directory. Trying cd m or even just m didn't work from outside that directory. I get:-
bash: cd: m: No such file or directory
Okay, so I thought maybe the PATH doesn't recognize directory paths. So I tried creating a bash script.
#!/bin/sh
cd ~/mydir/
Tried this, m...permission denied. Okay I thought and did chmod +x m to that file. And when I run that script like m then nothing. I tried ./m, still nothing.
I'm close to losing my mind to do such a simple task.
PATH is used to look for commands and I think a command ought to be a file or a symlink to a file.
So, cd m doesn't work as here the command is "cd" (not m). The lookup for "m" does not happen in PATH.
Just m does not work as the "m" found in PATH is a link to a directory and not a file. You can try creating another "m" which points to a file and put it in a directory later in the PATH and it will be recognized when you run just m.
The script you created does work, except that the cd now happens in a new shell and is lost at the end of the script. You can check this by putting an ls after the cd in your script.
There are a few ways to achieve what you want to do.
One option is to use the CDPATH variable. This is the search path for the cd command. Check man bash for details but basically, all you need to do is add your symlinks directory to CDPATH.
export CDPATH=~/symlinks:$CDPATH
cd m ## will cd to linked directory
Alternatively, you can create aliases or functions and put it in your .bashrc or another file which you then source.
alias m="cd ~/mydir"
m() {
cd ~/mydir
}
And now you can just type m to cd to mydir
Added to ~/.bash_profile
PATH=c:/Python27:$PATH
and
env | grep PATH
shows the path c:/Python27
However I cannot run python interpreter from command line in bash. I'm on Windows 7 and I can run python from any directory in command prompt after doing
path %path%;C:\Python
Or adding the path to my Environment Variables
In bash I am able to do other commands from any directory in terminal after adding their path to ~/.bash_profile given the path is a sub-directory of ~/
If the path in .bash_profile is C:/ rather than ~/ it doesn't work. So my question is when adding a path to .bash_profile where the location is in C:/ rather than ~/ how do i do it?
Bash uses : as the path separator, so you actually just added "c" and "/Python27" to your PATH.
Different Windows GNU toolset ports have different ways of working around this. You can try ls /c/, ls /cygdrive/c or read your port's documentation to see how it handles this.
If you find that e.g. /c/Python27 is mapped to c:\Python27, then you can add that to your path instead.
I want to add ./bin directory (which is relative to current shell directory) to $PATH on fish startup. Note that fish is a shell.
echo $PATH
set PATH ./bin $PATH
echo $PATH
If I place these lines inside ~/.config/fish/config.fish the shell will echo the same collection of paths. Absolute paths are added properly.
If I open the shell and type the same set PATH ./bin $PATH inside some directory containing bin it is added successfully. However when there is no bin inside current directory it shows me an error.
set: Could not add component ./bin to PATH.
set: Value too large to be stored in data type
I'm running fish 1.23.1 on OS X Lion.
The best way I have found to persistently add a path to your $PATH is
set -U fish_user_paths $fish_user_paths ~/path/name
This prepends to $PATH. And since it's persistent, the path stays in $PATH on shell restarts.
It's more efficient than putting a command in your config.fish to modify your $PATH, because it only runs once compared to running on every shell restart.
The variable fish_user_paths is intended to be set by the user1, as stated by ridiculousfish, the maintainer of fish.
Consider creating a fish function for convenience: 2
# ~/.config/fish/functions/add_to_path.fish
function add_to_path --description 'Persistently prepends paths to your PATH'
set --universal fish_user_paths $fish_user_paths $argv
end
And use it as:
$ add_to_path foo bar # Adds foo/ and bar/ to your PATH
Notes
On that page the author gives the example set -U fish_user_paths ~/bin. This overwrites fish_user_paths with a single value of ~/bin. To avoid losing existing paths set in fish_user_paths, be sure to include $fish_user_paths in addition to any new paths being added (as seen in my answer).
My dotfiles contain a slightly more advanced version that skips adding duplicates https://github.com/dideler/dotfiles/blob/master/.config/fish/functions/add_to_user_path.fish
I'd never heard of fish before this. I just installed it so I could try it out (and deleted a few paragraphs I had written here before realizing that fish is a shell).
It looks like set PATH dir-name $PATH is the right syntax to prepend a directory to $PATH.
But adding a relative directory name to $PATH is almost certainly a bad idea, and your shell is doing you a favor by warning you when the directory doesn't exist. (fish is designed to be user-friendly.)
Use an absolute path instead:
set PATH $PWD/bin $PATH
and first check whether $PWD/bin exists, printing an error message if it doesn't.
As for the "set: Value too large to be stored in data type" message, could you be adding the directory to your $PATH multiple times? There should be some way to check whether a directory is already in $PATH before adding it.
I think the answer is that using set -U is a red herring. Instead, add the following to ~/.config/fish/config.fish:
if status --is-interactive
set PATH $PATH ~/.local/bin;
end
direnv http://direnv.net/ is a good utility to help with what you're doing.
Generally, prepending $PATH with ./bin is insecure, as anyone with write-access to a shared directory could hide malicious code in e.g. ./bin/ls. That code would execute when you run ls in the shared directory.
direnv does not solve this problem (it works based on .envrc files, but anyone could be placing those), but at the very least it makes you aware when you cd into a directory that $PATH is getting modified:
$ cd my_project
direnv: loading .envrc
direnv export: ~PATH
It seems like fish won't add a non-existing directory path to PATH. That applies to relative paths too. But if you create bin directory in your home directory set PATH ./bin $PATH will work properly on each startup since it is executed from home. This is kind of a hack though.
Personally, I think there is only a small risk in adding . to the $PATH, so long as it's the last item, because a rogue ls (or whatever) in the CWD will not be found before /usr/bin/ls.
I add this in my config.fish:
contains '.' $PATH; or set --export PATH $PATH .
You could do similar for adding ./bin, again in the last position:
contains './bin'; or set --export PATH $PATH ./bin
Two things are going on here:
This is setting $PATH directly, just as with other shells. This won't persist across shells.
This checks that it's not already in the $PATH, so that sub-shells won't get longer, redundant entries in $PATH
I do not have su access and I have a perl executable in ~/et directory which is called exiftool.
I need to add that executable to bash commands (so that I can type exiftool instead of ~/et/exiftool).
The problem is that ~/et contains other files that are not executable (so I cannot use export PATH=$PATH:$HOME/et). Is there any alternative?
You could use an alias:
alias exiftool=~/et/exiftool
Or you can symlink it elsewhere and add that directory to your path:
mkdir -p ~/bin
ln -s ~/et/exiftool ~/bin
PATH=$HOME/bin:$PATH
I don't understand why having files that are not executable in the directory prevents you from adding the directory to your PATH anyway?
As an alternative, though, you can use an alias.
alias exiftool=$HOME/et/exiftool
You can place this in your .bashrc to have it always available.
softlink to a folder in PATH
alias exiftool='~/et/exiftool'