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

时间:2022-10-17 15:57:19

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.

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

Do somebody know of a way to achieve this?

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

I even thought about copy the cp or mv binary in the currentdir with

我甚至想过用currentdir复制cp或mv二进制文件

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.

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

thanks.

6 个解决方案

#1


10  

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

(Similar for Solaris, but I think the dynamic linker is named ld.so.1 or something along those lines.)

(类似于Solaris,但我认为动态链接器命名为ld.so.1或沿着这些行。)

Or, if your shell is sh-like (not csh-like),

或者,如果你的shell是sh(不像csh一样),

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

#2


5  

If you have prepared with sash pre-installed, then that is static and has a copy built-in (-cp).

如果您已预先安装了sash,那么它是静态的并且内置了一个副本(-cp)。

Otherwise LD_LIBRARY_PATH=/copied/to/path/lib /copied/to/path/bin/cp might work?

否则LD_LIBRARY_PATH = / copied / to / path / lib / copied / to / path / bin / cp可能有效?

I think it might have a problem with not having ld-so in the expected place.

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

#3


3  

Here's a reasonable ghetto replacement for cp. You'll want echo -E if the file ends with a new line (like most text files), echo -nE if it doesn't (like most binaries).

这是一个合理的贫民窟替代cp。如果文件以新行结束(如大多数文本文件),则需要echo -E,如果不是,则返回-nE(与大多数二进制文件一样)。

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

#4


0  

/subdir/bin/mv /subdir /

or am I missing something in your explanation?

或者我在你的解释中遗漏了什么?

#5


0  

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.

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

#6


0  

Old thread, but got exactly the same stupid mistake. /lib64 was moved to /lib64.bak remotely and everything stopped working.

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

This was a x86_64 install, so ephemient's solution was not working:

这是一个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

In that case, a different ld-linux had to be used:

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

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

Now the system is salvaged. Thanks ephemient!

现在该系统已被抢救。谢谢ephemient!

#1


10  

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

(Similar for Solaris, but I think the dynamic linker is named ld.so.1 or something along those lines.)

(类似于Solaris,但我认为动态链接器命名为ld.so.1或沿着这些行。)

Or, if your shell is sh-like (not csh-like),

或者,如果你的shell是sh(不像csh一样),

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

#2


5  

If you have prepared with sash pre-installed, then that is static and has a copy built-in (-cp).

如果您已预先安装了sash,那么它是静态的并且内置了一个副本(-cp)。

Otherwise LD_LIBRARY_PATH=/copied/to/path/lib /copied/to/path/bin/cp might work?

否则LD_LIBRARY_PATH = / copied / to / path / lib / copied / to / path / bin / cp可能有效?

I think it might have a problem with not having ld-so in the expected place.

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

#3


3  

Here's a reasonable ghetto replacement for cp. You'll want echo -E if the file ends with a new line (like most text files), echo -nE if it doesn't (like most binaries).

这是一个合理的贫民窟替代cp。如果文件以新行结束(如大多数文本文件),则需要echo -E,如果不是,则返回-nE(与大多数二进制文件一样)。

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

#4


0  

/subdir/bin/mv /subdir /

or am I missing something in your explanation?

或者我在你的解释中遗漏了什么?

#5


0  

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.

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

#6


0  

Old thread, but got exactly the same stupid mistake. /lib64 was moved to /lib64.bak remotely and everything stopped working.

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

This was a x86_64 install, so ephemient's solution was not working:

这是一个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

In that case, a different ld-linux had to be used:

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

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

Now the system is salvaged. Thanks ephemient!

现在该系统已被抢救。谢谢ephemient!