This problem is killing me and I feel like I've tried everything.
First off, the problem started happening when upgrading to Capistrano 3. Capistrano now utilizes /usr/bin/env before every command when deploying, to make sure the environment setup is correct.
When Capistrano goes to create symlinks to the necessary shared directory and respective files, it attempts commands like:
/usr/bin/env ln -s /full/path /different/full/path
...and then it errors out:
/usr/bin/env: ln: Too many levels of symbolic links
I realize it's not Capistrano's fault, so I began troubleshooting by ssh'ing to my server and trying the same command, and I receive the same error (which at least is good for consistency). I then try the same command without /usr/bin/env:
ln -s /full/path /different/full/path
And it works!!!! Maybe you can see the real solution that I can't?
here is the output of just the /usr/bin/env command:
rvm_bin_path=/home/deployer/.rvm/bin
GEM_HOME=/home/deployer/.rvm/gems/ruby-1.9.3-p392
TERM=xterm-256color
SHELL=/bin/bash
IRBRC=/home/deployer/.rvm/rubies/ruby-1.9.3-p392/.irbrc
SSH_CLIENT=...
OLDPWD=/home/deployer/Sites/example.com
MY_RUBY_HOME=/home/deployer/.rvm/rubies/ruby-1.9.3-p392
SSH_TTY=/dev/pts/0
USER=deployer
LS_COLORS= .....
_system_type=Linux
rvm_path=/home/deployer/.rvm
SSH_AUTH_SOCK=....
rvm_prefix=/home/deployer
MAIL=/var/mail/deployer
PATH=/home/deployer/.rvm/gems/ruby-1.9.3-p392/bin:/home/deployer/.rvm/gems/ruby-1.9.3-p392#global/bin:/home/deployer/.rvm/rubies/ruby-1.9.3-p392/bin:/home/deployer/.rvm/bin:/opt/rubyee/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/deployer/.rvm/bin
PWD=/home/deployer/Sites
LANG=en_US.UTF-8
_system_arch=i386
_system_version=12.04
rvm_version=1.26.4 (latest)
SHLVL=1
HOME=/home/deployer
LOGNAME=deployer
GEM_PATH=/home/deployer/.rvm/gems/ruby-1.9.3-p392:/home/deployer/.rvm/gems/ruby-1.9.3-p392#global
SSH_CONNECTION=....
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
RUBY_VERSION=ruby-1.9.3-p392
_system_name=Ubuntu
_=/usr/bin/env
I have also tried commands like the following, to find potential symlink loops:
find . -maxdepth 20 -type l -exec ls -ld {} +
But is not producing correct results:
lrwxrwxrwx 1 deployer deployer ...
You might not being using the same ln utility.
When invoking it directly from the interactive shell, ln might be overridden e.g. by an alias or by some shell function ln() {...;}.
This does not happen when /usr/bin/env tries to do that (AFAIK it looks for ln in PATH). I suspect that the ln it finds has issues, so you are getting this error.
This is an example scenario that might be similar to your case:
# start from an empty directory
$ ls -l
total 0
# create a problematic `ln` in the current directory
$ ln -s ln ln
$ ls -l
total 0
lrwxrwxrwx 1 me me 2 Jan 7 20:28 ln -> ln
# have an alias for the "real" ln
$ alias ln=/bin/ln
# mess up PATH
$ PATH="$PWD"
Now let's try the two alternatives, /usr/bin/env goes first:
$ /usr/bin/env ln -s /some/path /tmp/path
/usr/bin/env: ln: Too many levels of symbolic links
Then plain ln (remember that we aliased it):
$ ln -s /some/path /tmp/path
$ echo $?
0
$ /bin/ls -l /tmp/path
lrwxrwxrwx 1 me me 10 Jan 7 20:31 /tmp/path -> /some/path
So my suggestion is: look at issues with ln, e.g. by finding all different alternatives that might be visible. In bash you might run this:
$ type -a ln
Try this to find symlink loops:
find . -follow -printf ""
if you are using docker so you should install ruby in your case
docker run ruby
source
https://github.com/docker/for-win/issues/5763#issuecomment-585749243
Related
From what I've read, [command] -h or [command --help can be used to get help about a command in the shell, but on my Mac OS Big Sur 11.4, I keep getting errors/unexpected results:
lorax#Loras-MacBook-Pro ~ % pwd --help
pwd: bad option: -h
lorax#Loras-MacBook-Pro ~ % pwd -h
pwd: bad option: -h
lorax#Loras-MacBook-Pro ~ % ls --help
ls: illegal option -- -
usage: ls [-#ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1%] [file ...]
lorax#Loras-MacBook-Pro ~ % ls -h
Applications Inbox eclipse-workspace
Desktop Library nltk_data
Documents Movies venv
Downloads Music venvV
ENV Pictures
G Drive Public
lorax#Loras-MacBook-Pro ~ % cd --help
cd: no such file or directory: --help
lorax#Loras-MacBook-Pro ~ % cd -h
cd: no such file or directory: -h
Meanwhile, flags with similar functions such as man [command] (and every other command I've tried so far for that matter) seem to work fine.
I'm very new to the shell/command line, so any insight as to why this is happening/what I did wrong would be greatly appreciated!
command and binary are different. pwd and cd are builtin commands by your shell (bash, zsh, etc), while ls is a real binary in (by default is /bin/ls). you can check where a binary located with which ls. Usually, but not all, binaries have --help argument, but of course not buildint command.
i recommend you to use man for manual of any commands. for example: man ls man pwd man which
❯ which cd
cd: shell built-in command
~
❯ which pwd
pwd: shell built-in command
~
❯ which ls
ls: aliased to lsd
~
❯ which lsd
/opt/homebrew/bin/lsd
Here is the story:
cd ~
mkdir bin
export PATH=$PATH:bin
mkdir -p projects
cd projects
echo 'hello world' > hello.sh
chmod +x hello.sh
ln -s hello.sh ~/bin/hello
hello
output:
-bash: hello: command not found
How I changed it:
ln -s hello.sh ~/bin
hello.sh
The output is more weird:
-bash: /home/qht/bin/hello.sh: Too many levels of symbolic links
I ls it to see what happened:
ls -l ~/bin/hello.sh
/home/qht/bin/hello.sh -> hello.sh
I figure it out, hello.sh reference itself. And hello before reference hello.sh which doesn't exist.
I fix it by:
ln -sf $PWD/hello.sh ~/bin/hello
ls ~/bin/hello
/home/qht/bin/hello -> /home/qht/projects/hello.sh
and it works, I also man ln to see if there is a convenient option to do that, this is what I found:
ln -sfr hello.sh ~/bin/hello
ls -l ~/bin/hello
/home/qht/bin/hello -> ../projects/hello.sh
And it works, the -r option did the work.
But I'm curious, if ln -r can automatically write the relative path data into symbolic links, Why doesn't there an option maybe -a to do the absolute path work.
Or, is relative path for links is more practical than absolute path?
Try this:
cd ~
mkdir bin
export PATH=$PATH:~/bin # Need absolute path to bin
mkdir -p projects
cd projects
echo 'echo "hello world"' > hello.sh # If the script is just hello world
# this will become an infinite loop
chmod +x hello.sh
ln -s "$PWD/hello.sh" ~/bin/hello # the symbolic link in this case
# needs to be a absolute path
hello
I'm working on an automated installation of a openSUSE system using AutoYAST, and I'm stumped on a small detail. In order to setup relevant applications in the user's environment, I try to symlink to all applications located in /usr/local/bin in ~/bin (so say /usr/local/bin has the addr2line utility, then I want to have a symlink to that in ~/bin).
I've tried to execute the following snipped to accomplish this:
su -c "for program in `ls /usr/local/bin`; do ln -s /usr/local/bin/$program ~/bin/$program; done" <user>
This snippet executes in the post-script phase of the automatic installation, which is executed as root (and seeing as I want the owner of the symlinks to be the user, this command is executed using su).
However, this does not work, and gives the following output:
++ ls /usr/local/bin
+ su -c 'for program in addr2line
ar
as
c++
c++filt
cpp
elfedit
g++
gcc
gcc-ar
gcc-nm
gcc-ranlib
gcov
gprof
i686-pc-linux-gnu-c++
i686-pc-linux-gnu-g++
i686-pc-linux-gnu-gcc
i686-pc-linux-gnu-gcc-4.9.3
i686-pc-linux-gnu-gcc-ar
i686-pc-linux-gnu-gcc-nm
i686-pc-linux-gnu-gcc-ranlib
ld
ld.bfd
nm
objcopy
objdump
ranlib
readelf
size
strings
strip; do ln -s /usr/local/bin/ ~/bin/; done' <user>
bash: -c: line 1: syntax error near unexpected token `ar'
bash: -c: line 1: `ar'
I've tried several variations of the command, but all seem to not exactly do what I want.
For example, I've also tried:
su -c "for program in /usr/local/bin/*; do ln -s $program ~/bin/; done" <user>
But this only created a symlink to /usr/local/bin in ~/bin.
So I'm a bit stuck on this one... Does anybody have an idea?
You're using double quotes to define your su command, so $program is being evaluated immediately. You want it evaluated when su executes the command. Use single quotes instead:
su -c 'for program in `ls /usr/local/bin`; do ln -s /usr/local/bin/$program ~/bin/$program; done' <user>
You can also use cp -s to create symlinks on a system with GNU cp (like your suse system), which gives you the ability to use recursion and the other fun options of cp.
In the end, I decided to go with the command posted by pacholik to fix this, as my original attempt was over-engineered and thus not necessary.
ln -s /usr/local/bin/* ~/bin
I installed rvm 1.9.3 and now whenever I switch to a directory containing a .rvmrc, I get a perl error message:
~/example$ cd .. && cd example
perl version 5.12.3 can't run /usr/bin/shasum. Try the alternative(s):
/usr/bin/shasum5.10.0 (uses perl 5.10.0)
Run "man perl" for more information about multiple version support in
Mac OS X.
You may try this dirty approach. This approach will skip those check and directly use shasum in your binary directory
$ cd /usr/bin
$ ls shasum*
shasum shasum5.10.0
$ mv /usr/bin/shasum /usr/bin/your_backup_shasum
$ ln -s shasum5.10.0 shasum
I have a "gtags" executable in /usr/bin, but this is an older one.
Then I've compiled a new gtags and "make install" puts it in /usr/local/bin.
then I removed the one in /usr/bin. But when I typed "gtags" in shell, it told me that "/usr/bin/gtags" cannot found. But I have a "gtags" in /usr/local/bin, and the /usr/local/bin is in the PATH. Also, in my PATH, the /usr/local/bin is searched before /usr/bin, why the shell only checked "gtags" in /usr/bin?
Use the bash built-in command hash:
[root#localhost ~]# touch /bin/test.sh
[root#localhost ~]# chmod 755 /bin/test.sh
[root#localhost ~]# test.sh
[root#localhost ~]# mv /bin/test.sh /usr/local/bin/
[root#localhost ~]# test.sh
-bash: /bin/test.sh: No such file or directory
[root#localhost ~]# hash test.sh
[root#localhost ~]# test.sh
The reason this happens is bash "caches" where the binary is in $PATH so it doesn't have to find it each time it wants to run it. It's a performance thing. If you run "hash" with no arguments it'll report which commands its ran, how many times, and where it ran it from.