Can ZSH be configured so that, just like Bash, it disregards subdirectories contained in the directories listed in $PATH?
According to Bart Schaefer seemingly the subfolders contained in the folders listed in $PATH are handled like executables in ZSH (whereas Bash disconsiders them).
For example, if $PATH contains the folder /usr/local/bin and there is a subfolder md5 in /usr/local/bin (but no such executable in a path of $PATH after it), then typing md5 and Enter gives the response zsh: permission denied: (instead of command not found in Bash) because md5 is not a command, but a directory.
This can bite you, for example, when a script checks on Linux whether the command md5 is available (as it is, by default on MacOS), and zsh wrongly returns true (the proper command would be md5sum). This is a frequent issue on WSL which converts and appends all paths in %PATH% to $PATH.
Similar questions have been asked in "zsh: permission denied: gam" and "Weird rails error "permission denied: bin/rails" for old rails apps", but the answers did not get to the heart of the matter.
Related
I'm sort of new to programming (not really, but I'm still learning - aren't we all?). Although I know Java and Python and sort of know C, C++, JS, C#, HTML, CSS, etc. (and I can navigate pretty well in the terminal), I am not familiar with what $PATH is in the terminal.
I've been using the Linux terminal and Mac terminal much more frequently than I used to (if I even did at all two years ago), and I know for python, it wants you to "export" its path like PATH=\path\to\python\bin:${PATH}\ export PATH. However, I don't even know what it does. I tried to find out, but all I could find were people saying "export this path and export that one."
So, what is it and why use it? I understand that (if you do it for Python), it basically makes 'python' (or 'python2' or 'python3') a variable, but I just don't understand the concept of what it is.
man bash describes it as:
PATH
The search path for commands. It is a colon-separated list of
directories in which the shell looks for commands (see COMMAND
EXECUTION below). A zero-length (null) directory name in the
value of PATH indicates the current directory. A null directory
name may appear as two adjacent colons, or as an initial or
trailing colon. The default path is system-dependent, and is
set by the administrator who installs bash. A common value is
/usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin'.
When you run a command, like python, the operating system tries to find the python program in the list of directories stored in PATH.
Suppose your PATH is /usr/local/bin:/foo:/bar:/baz:/usr/bin. When you try to run the python comamnd, the operating system will look for an executable named python in those directories in order. On Linux, you can watch it do this with the strace command:
$ PATH=/usr/local/bin:/foo:/bar:/baz:/usr/bin strace -f /bin/bash -c 'python --version' 2>&1 | grep 'stat.*python'
stat("/usr/local/bin/python", 0x7fff98b63d00) = -1 ENOENT (No such file or directory)
stat("/foo/python", 0x7fff98b63d00) = -1 ENOENT (No such file or directory)
stat("/bar/python", 0x7fff98b63d00) = -1 ENOENT (No such file or directory)
stat("/baz/python", 0x7fff98b63d00) = -1 ENOENT (No such file or directory)
stat("/usr/bin/python", {st_mode=S_IFREG|0755, st_size=4864, ...}) = 0
As soon as python is found in /usr/bin/python, the search stops, and the program runs.
My vagrant VM box is super slow when I try to run my Rails app on it, and I'm guessing it's due to the shared folder problem.
I am trying to use rsync to circumvent the problem.
I installed Cygwin and necessary packages, put C:\cygwin64\bin; as PATH environment variable
and then changed my Vagrantfile to
config.vm.synced_folder ".", "/vagrant", type: "rsync"
When I run vagrant up, I Get this error message
$ vagrant up Bringing machine 'default' up with 'virtualbox'
provider... "rsync" could not be found on your PATH. Make sure that
rsync is properly installed on your system and available on the PATH.
What's going wrong here?
Thank you so much ... if there's any other way to run Vagrant VM box smoothly and faster on Windows 7, I would love to hear it too.
This turned out to be a bunch of brick-walls you have to circumvent when installing Rsync and setting it up correctly for Vagrant on Windows 7.
First of all, the error "rsync" could not be found on your PATH. Make sure that rsync is properly installed on your system and available on the PATH. was due to the fact that
1) Environment variable for Cygwin was placed in the latest order in the PATH, I changed it to the beginning of the path
2) During installation of Cygwin and Rsync, I installed individual "subpackages" instead of installing everything, thinking that it would be okay. Turns out I was wrong. I installed everything in the Admin package and Net package (not the SRC but just the bins), and then it started working. I suggest you set-up Cygwin again and really try to download everything if you see that error.
(I found these solutions through this post on SO cygwin + rsync)
Now, I could go into CMD and type rsync, and it would show up correctly. But then when I ran vagrant up it gave me another error saying
There was an error when attempting to rsync a synced folder. Please inspect the error message below for more info.
Host path: /c/Users/xxxxx Guest path: /vagrant
Command: rsync --verbose --archive --delete -z --copy-links
--chmod=ugo=rwX --no-perms --no-owner --no-group --rsync-path sudo rsync -e ssh -p 2222 -o StrictHostKeyCh
/c/Users/xxxx / vagrant#127.0.0.1:/vagrant
Error: cygwin warning: MS-DOS style path detected:
C:/Users/xxxxxxx Preferred POSIX
equivalent is:
/cygdrive/c/Users/xxxx CYGWIN
environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of
known hosts. rsync: change_dir "/c/Users/xxxxxxx"
failed: No such file or directory (2) rsync error: some files/attrs
were not transferred (see previous errors) (code 23) at
/usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/main.c(1052)
[sender=3.0.9]
I googled solution to this error and found this site. https://github.com/mitchellh/vagrant/issues/3230
Then there's a bug with Vagrant and cwrsync that I mentioned in #3086.
For now, just edit
C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.5.1\plugins\synced_folders\rsync\helper.rb
and add hostpath = "/cygdrive" + hostpath to line 74. It's a terrible
solution but quick and simple.
Editing that helper.rb file and adding hostpath at line 74 (just made some blank lines right there and pasted it in) and now it works perfectly!!!!
Rsync makes the shared folder soooooo much faster on Rails!!!! I think it is worth the pain of setting it up correctly. Try it!!
It's not clear from your message, but I think you installed rsync on your machine (the host), while it needs to be installed on the virtual machine you bringing up (the guest).
Trying to get a rails server running nicely.
downloaded ruby 1.8.7 using link from rails page.
did ./configure/make/install, installed it fine.
tried ruby -v , got nothing.
tried ./ruby -v from the folder and it worked.
I feel like i've gone from understanding something about unix, to completely lost. Clearly ruby is working as a 'daemon', but not running as it should. Any help would be MUCH appreciated. Losing too much hair through this process :(
J.
can you see where make install put the ruby executeable?
if you do, check if this dir is in your $PATH by
echo $PATH
In general, unix needs to know where to find the executable file to be able to run it. It uses $PATH to find this executable file.
So if you type "ruby" it will go look at you $PATH and then look in each of those directories for a file named "ruby". If it can't find it in any of those directories it should then also look in the current directory.
So, this whole process will fail if:
a) the directory that contains the executable ruby file is not in any of the directories in $PATH AND
b) the executable is not in the current directory
... one more alternative is that is is available in one of these directories... but is not actually marked as being executable by you. You can check this by making sure you're int e directory with the ruby file and typing "ls -l ./ruby"
That will list the ruby file along with all its permissions and who owns it.
It should be something like:
lrwxrwxrwx 1 root root 7 2010-02-14 10:45 ./ruby
Notice the rwx. If your ruby doesn't have x then you'll need to add executable permission using chmod eg: "chmod 755 ./ruby"
Also note the "root root" - that means it's owned by root - in general, this means that only root can run it. In this particular example it has eXecute permission for everyone so everybody can run it, but if you do not have execute permission set like this, then it means that if you are trying to run it as yourself, you won't have permission, and you should either add full permissions or try running it using: "sudo ruby"
However - by the sounds of it - the most likely problem is that you just don't have the ruby executable's directory in your $PATH. You will need to fix this even if you get it running right now - because, in future, you will need to run ruby from directories other than the current one.
You will need to google for instructions on adding things to your $PATH - because it differs depending on your version of linux and your current shell, but it's not very difficult.
Which shell are you running? If tcsh, you may need a "rehash". Otherwise, as leifg says, add the directory containing the ruby executable to your path.
I was trying to set up a bash command in Terminal on a Mac.
The scripts run correctly when I execute them directly.
I set up symlinks in /usr/local/bin/ to the current location of the scripts. When I try to run it off the symlink, it doesn't work. I don't believe the issue is the $PATH, because pip, git, ipython all exist in this location. When I edit the $PATH setting, these fail.
Suggestions?
ls -l /usr/local/bin/foo and see where your symlink is actually pointing. Betcha it's broken.
If not, try running /usr/local/bin/foo. If that works, it was your PATH that's wrong, despite what you said in the OP.
The only other thing that would cause this behavior is if the script is reading $0 (its own name as executed). With a symlink, that will have a different value.
I found my own answer... The symlinks were created by an automated file which was gabbing my pwd. I was also using virtualenv, so to get it to work, I had to activate the virtualenv and be inside the folder that had the script that created the symlinks.
I install my commands in $HOME/bin instead of /usr/local/bin, but it does not matter much. As hinted in the comments, one question is whether the symlinks are set correctly.
Check which command the shell thinks you should execute: which command
Check that the link in /usr/local/bin points to the correct file (and has execute permission, etc):
ls -l /usr/local/bin/command
ls -lL /usr/local/bin/command
Check that the interpreter path in the shebang is correct:
file /usr/local/bin/command
Check that /usr/local/bin is actually on your PATH: echo $PATH
If none of that shows up a problem, show us the results of the commands above.
Passenger says:
Ruby on Rails application could not be started
...
Command 'exiftool' not found (MiniExiftool::Error)
When I login with ssh and I type exiftool in any directory the command works properly.
I have the follwing line in both .bash_profile and .bashrc
export PATH=$PATH:$HOME/bin
Is it possible that Rails (MiniExiftool plugin) does not recognize that bash command? How can I fix this behaviour?
The PATH for the user your server runs as does not include the directory that exiftool is in. You can either add it to that user's path, or you can refer to exiftool using its full path. I'd recommend this second approach for reasons of security. There are a number of attacks that involve putting trojan horses in a user's path ahead of the directories where the real binaries live.