我已经设置了完整的工作 debootstrap-ed arm chroot 环境。我可以chroot在其中运行命令等。
我正在制作一个自定义 chroot env 的脚本，但我对此很挣扎。
例如：
chroot $target_dir echo this is a test > /tmp/test
谁能向我解释一下，为什么在这个示例中我得到的输出是在我的主机环境中写入的，而不是在 chrooted 中？
只是提一下，我可以执行 fe
echo this is a test > $target_dir/tmp/test
但我想知道为什么 chrooted 执行“失败”
编辑：
这也有效：
chroot $target_dir /bin/bash -c "echo test > /tmp/test"
答案1
当你跑步时：
chroot $target_dir echo this is a test > /tmp/test
这种> /tmp/test情况发生在“chroot”命令中，就像您编写的那样：
> /tmp/test chroot $target_dir echo this is a test
如果您希望重定向发生在 chroot 命令内部，一种方法是：
chroot $target_dir sh -c 'echo this is a test > /tmp/test'
...因为这会放入shchroot 中，让 echo 看到正确的重定向目录。
答案2
重定向实际上并未发生在chroot.> /tmp/test由您使用的任何 shell 处理。如果你实际上传递> /tmp/test到chroot，然后它会被传递到echo，你会看到
this is a test > /tmp/test
在您的终端上。当然，你的 shell 不会被chroot编辑，所以打开就完全没问题/tmp/test。然后，shell execschroot可执行文件，它调用chroot系统调用，然后execs into echo，最后写入 fd。整个过程中，您的（un ed）shell 打开的原始文件描述符chroot从未被修改，因此您的chrootedecho能够写入它。
这是一个故意的功能。允许之外的进程chroot打开文件，然后其chrooted 子进程只能访问chroot父进程设计传递给它们的之外的那些文件。
如果您希望进行重定向里面对于 chroot，您需要生成一个知道如何解释它的 shell：
chroot $dir bash -c "echo this is a test > /tmp/test"
现在的操作顺序是：（fork使用默认的 stdin、stdout 和 stderr）、、exec chroot（chroot现在在 chroot 内）、exec bash（知道如何处理重定向）、fork（的实现细节bash）、打开文件、exec echo（使用新的 stdout）。