仅使用 bash 内置命令在 linux/solaris 中移动/复制文件/文件夹
有一种情况，有人将整个 rootdir 移动到远程系统上的子目录中，因此所有系统工具（如 cp、mv 等）不再工作。虽然我们有一个活跃的会话，但找不到仅使用 bash 内置程序来复制/移回文件的方法。
有人知道实现这一目标的方法吗？
我什至考虑过复制当前目录中的 cp 或 mv 二进制文件
while read -r; do echo $LINE; done
，然后将其重定向到文件，但它不起作用。猜测是因为二进制文件中的所有特殊的不可打印字符无法使用 echo 复制/显示。
谢谢。
There was a situation when somebody moved the whole rootdir into a subdir on a remote system, thus all the system tools like cp, mv, etc didn't work anymore. We had an active session though but couldn't find a way to copy/move the files back using only bash built-ins.
Do somebody know of a way to achieve this?
I even thought about copy the cp or mv binary in the currentdir with
while read -r; do echo $LINE; done
and then redirect this to a file, but it didn't work. Guess because of all the special non printable chars in a binary file that can't be copied/displayed using echo.
thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
（对于 Solaris 类似，但我认为动态链接器被命名为 ld.so.1 或类似的名称。）
或者，如果您的 shell 类似于 sh（而不是类似于 csh），
(Similar for Solaris, but I think the dynamic linker is named
ld.so.1or something along those lines.)Or, if your shell is sh-like (not csh-like),
如果您已准备好预安装的
sash，那么它是静态的并且具有内置副本 (-cp)。否则
LD_LIBRARY_PATH=/copied/to/path/lib /copied/to/path/bin/cp可能有效？我认为可能有问题，因为 ld-so 没有出现在预期的位置。
If you have prepared with
sashpre-installed, then that is static and has a copy built-in (-cp).Otherwise
LD_LIBRARY_PATH=/copied/to/path/lib /copied/to/path/bin/cpmight work?I think it might have a problem with not having ld-so in the expected place.
这是 cp 的一个合理的 ghetto 替代品。如果文件以换行符结尾（像大多数文本文件一样），则需要
echo -E；如果文件不以换行符结尾（像大多数二进制文件一样），则需要echo -nE。Here's a reasonable ghetto replacement for
cp. You'll wantecho -Eif the file ends with a new line (like most text files),echo -nEif it doesn't (like most binaries).老线程，但犯了完全相同的愚蠢错误。 /lib64 被远程移动到 /lib64.bak，一切都停止工作。
这是 x86_64 安装，因此 ehemient 的解决方案不起作用：
在这种情况下，必须使用不同的 ld-linux：
现在系统已被抢救。谢谢易显！
Old thread, but got exactly the same stupid mistake. /lib64 was moved to /lib64.bak remotely and everything stopped working.
This was a x86_64 install, so ephemient's solution was not working:
In that case, a different ld-linux had to be used:
Now the system is salvaged. Thanks ephemient!
或者我在你的解释中遗漏了什么？
or am I missing something in your explanation?
如果您可以访问另一台计算机，一种解决方案是下载并编译 Busybox 二进制文件。它将是一个包含恢复系统所需的大多数常用工具的单个二进制文件。如果您的系统是远程的，这可能不起作用。
If you have access to another machine, one solution is to download and compile a Busybox binary. It will be a single binary contains most of the common tools you need to restore your system. This might not work if your system is remote though.