rnr is deprecated in favour of fcd (https://github.com/bugnano/fcd)
The RNR File Manager (RNR's Not Ranger) is a text based file manager that combines the best features of Midnight Commander and Ranger.
Its main goal is to be the most robust file copier in existence.
https://www.youtube.com/watch?v=dHh-7hX6dRY
https://www.youtube.com/watch?v=17-K43Z2XcU (Italian)
# To install or upgrade
pip3 install --user --upgrade rnr
# To run
rnr
If you're using bash and you want to change directory on exit, you have to add
a line like this in your ~/.bashrc
:
source ~/.local/share/rnr/rnr.sh
If you're using fish, then simply copy (or, better, symlink) the file
~/.local/share/rnr/rnr.fish
to ~/.config/fish/functions/
(create the
directory if it does not exist).
Note that this script requires at least fish version 3.1.0
In order to enable the CTRL-Q and CTRL-S key combinations, put the following
line in your ~/.bashrc
or ~/.config/fish/config.fish
:
stty -ixon
The rnr man page can be invoked with the command:
man rnr
Here is a text version of the man page
File copying looks like a simple operation, but there are many cases where it could go wrong.
To better understand the situation, let me tell you a couple of stories:
You have several big, multi-gigabyte files that you need to copy from one hard drive to another. This operation is very time consuming, so you start the copy process in the evening, and let it run overnight.
The next day, you wake up, and see that the copy process is stuck at 10% and you see a window prompting you what to do, as there already is a file with the same name in the destination directory (or an error has occurred during the copy, and the program is asking you if you want to continue or abort).
Result: you wasted almost the whole night, as the copy process was waiting for your input.
Now imagine instead that you wake up and see that your computer shows an empty desktop because the power went down in the night.
Result: The copy process has been interrupted and you have no idea which files have been copied and which files not.
There must be a better way! - Raymond Hettinger
So rnr addresses these problems in 2 ways:
Now, let's address the elephant in the room: The on-disk database slows down operations considerably in the case of many small files.
While rnr defaults to using a database file, it is in fact optional, and can be disabled by a command line switch, or by the "No DB" button.
Of course, everything said about the file copy is applied to the file move operation as well.
If you're packaging rnr for your distribution, consider copying (or symlinking)
the rnr.sh
file to the /etc/profile.d
directory, and the rnr.fish
file to
the /etc/fish/functions
directory, so that rnr automatically changes directory
on exit, without needing manual configuration.