Ruby /usr/bin/env:ln:符号链接级别太多

这个问题折磨着我，我觉得我什么都试过了

首先，问题是在升级到Capistrano 3时开始出现的。Capistrano现在在部署时在每个命令之前使用/usr/bin/env，以确保环境设置正确

当Capistrano创建指向必要共享目录和相应文件的符号链接时，它会尝试以下命令：

/usr/bin/env ln -s /full/path /different/full/path

…然后它会出错：

/usr/bin/env: ln: Too many levels of symbolic links

我意识到这不是Capistrano的错，所以我开始通过ssh到我的服务器并尝试相同的命令来进行故障排除，我收到了相同的错误（这至少有利于一致性）。然后在不带/usr/bin/env的情况下尝试相同的命令：

ln -s /full/path /different/full/path

而且很有效！！！！也许你能看到我看不到的真正解决办法

以下是/usr/bin/env命令的输出：

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

我还尝试了以下命令来查找潜在的符号链接循环：

find . -maxdepth 20 -type l -exec ls -ld {} +

find . -follow -printf ""

但没有产生正确的结果：

lrwxrwxrwx 1 deployer deployer ...

---

尝试以下操作以查找符号链接循环：

find . -maxdepth 20 -type l -exec ls -ld {} +

find . -follow -printf ""

---

您可能没有使用相同的

ln

实用程序

当直接从交互式shell调用它时，

ln

可能会被覆盖，例如被

别名

或某个shell函数

ln（）{…；}

覆盖

当

/usr/bin/env

尝试这样做时，不会发生这种情况（在

路径中查找
ln
）。我怀疑它找到的
ln
有问题，因此您得到了这个错误

这是一个可能与您的案例类似的示例场景：

# 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"

现在，让我们尝试两种选择，
/usr/bin/env
首先：

$ /usr/bin/env ln -s /some/path /tmp/path
/usr/bin/env: ln: Too many levels of symbolic links

然后是普通的
ln
（记住我们
alias
ed它）：

因此，我的建议是：查看
ln
的问题，例如，通过找到所有可能可见的不同备选方案。在
bash
中，您可以运行以下命令：

$ type -a ln

capistrano试图创建的符号链接已经存在，当您运行部署时，它会自动循环并创建此错误。您可以使用set:default\u env在capistrano脚本中设置默认环境路径。你也可以发布你的.bash_档案吗？Capistrano始终分配一个非登录、非交互的shell，以便在登录时查找sup for.bash_概要文件。有了它也会有所帮助。正如我在最初的帖子中所说的，我能够在没有capistrano的情况下测试这个问题，通过ssh’ing到我的服务器并尝试使用相同的命令，前缀是/usr/bin/env。因此，我可以证明卡皮斯特拉诺不是原因。此外，事实的符号链接还不存在。正如我所说，当在我的服务器上手动尝试与capistrano相同的命令时，我得到了相同的错误。（我还阅读了cap 3的所有文档，我知道：default_env变量，但正如我所说，问题不在capistrano之内。）我也会发布我的.bashrc和.profile。试着在
strace
下运行它？正如在
strace/usr/bin/env-ln-s/full/path/different/full/path
中一样，这可能会提供一个提示。您没有看到我已经尝试过的命令吗<代码>查找-maxdepth 20-type l-exec ls-ld{}+

（这个更详细）。不，输出什么都不是。