Question

有人将整个rootdir移动到远程系统上的子目录中，因此所有系统工具（如cp，mv等）都不再起作用。我们有一个活跃的会话但是找不到使用bash内置函数复制/移动文件的方法。

有人知道实现这个目标的方法吗？

我甚至想过用

复制currentdir中的cp或mv二进制文件

while read -r; do echo $LINE; done

然后将其重定向到文件，但它不起作用。因为二进制文件中所有特殊的不可打印字符无法使用echo复制/显示，所以猜猜。

感谢。

Answer 1

/newroot/lib/ld-linux.so.2 --library-path /newroot/lib \
    /newroot/bin/mv /newroot/* /

（类似于Solaris，但我认为动态链接器的名称为ld.so.1或类似的东西。）

或者，如果你的shell是sh（不像csh那样），

LD_LIBRARY_PATH=/newroot/lib /newroot/bin/mv /newroot/* /

Answer 2

如果您已预先安装了sash，那么这是静态的，并且内置了一个副本（-cp）。

否则LD_LIBRARY_PATH=/copied/to/path/lib /copied/to/path/bin/cp可能有用吗？

我认为在预期的地方没有ld-so可能会有问题。

Answer 3

这是cp的合理贫民窟替代品。如果文件以新行结束（如大多数文本文件），则需要echo -E，如果不是（如同大多数二进制文件），则需要echo -nE。

echo -nE "`< in.file`" > out.file

Answer 4

/subdir/bin/mv /subdir /

或者我在解释中遗漏了什么？

Answer 5

如果您有权访问另一台计算机，一种解决方案是下载并编译Busybox二进制文件。它将是一个单独的二进制文件，包含恢复系统所需的大多数常用工具。如果你的系统是远程的，这可能不起作用。

Answer 6

旧线程，但得到完全相同的愚蠢错误。 / lib64远程移动到/lib64.bak，一切都停止了。

这是一个x86_64安装，所以ephemient的解决方案无效：

# /lib64.bak/ld-linux.so.2 --library-path /lib64.bak/ /bin/mv /lib64.bak/ /lib64
/bin/mv: error while loading shared libraries: /bin/mv: wrong ELF class: ELFCLASS64

在这种情况下，必须使用不同的ld-linux：

# /lib64.bak/ld-linux-x86-64.so.2 --library-path /lib64.bak/ /bin/mv /lib64.bak/ /lib64

现在系统已被抢救。谢谢ephemient！

仅使用bash内置函数在linux / solaris中移动/复制文件/文件夹

6 个答案: