Hi all, this post comes from here.
Yes, there are already existed shell commands rename
and mv
for batch renaming, being very simple to use.
There's no reason to reinvent the wheels, I agreed.
But one day, I overwrote some important files in a batch renaming operation, which might be family images or raw reads. You know, removed files can be found in the trash or recovered, but overwritten files are nearly impossible to recover. Therefore I decided to write a safer batch renaming tool, that could detect overwriting conflicts.
That is the brename: a CLI tool for safely batch renaming files/directories via regular expression.
Here are some main reasons:
- Brename supports dry run, by showing which files are going to be renamed and what the new names are. This makes users feel safe.
- Besides, it detects potential overwriting conflicts before renaming, which helps avoid overwriting important files like raw FASTQ reads.
- At last, it can undo the last operation like the
ctrl + z
shortcut. This gives users a chance to rescue the wrong move. This is extremely useful when newly renamed contain less information to recover the original names, that is to say, you can't re-batch-rename.
Extra bonus:
- Easy to install. Providing statically-linked executable binary files for Linux, Windows, and macOS.
- Recursively renaming both files and directories.
- File filtering. Supporting including and excluding files via regular expression.
No need to run commands like
find ./ -name "*.html" -exec CMD
. - Renaming submatch with corresponding value via key-value file.
- Renaming via ascending integer.
Similar tools: here's a benchmark of similar tools, brename
ranks 2nd. But safety is the most important point.
Love the undo option - I think only emacs' dired mode would have something similar.
The benchmark is not really useful, as speed is not a big concern here - like you say, safety is way more important. In fact, I recommend to all users that they alias
rm
torm -iv
andmv
tomv -iv
for safety and verbosity.You say that brename detects potential conflicts before overwriting. Not including the dry-run option, how is this detection different from
mv -i
?mv -i
shows the conflicts but you need to confirm the operations one by one. And it can not detect overwriting conflicts shown as below.Just an example here, but it may happen for some reason. Suppose we might remove the
_1
and_2
using some renaming pattern by accident.For
mv
, you may use aloop
for batch renaming.read_1.fq.gz
toread.fq.gz
. It's OK, no conflict.read_2.fq.gz
toread.fq.gz
. Hmm, looks OK formv -i
. But it actually overwrites the newly renamed file.Look how
brename
does:BTW, I want to test
rename
, but it seems to not recognize regular expressions???The fact that
mv
does not check newly renamed files is news to me. I wonder why that is - I'd expect mv to check right before the mv operation, not before the loop begins.I don't use rename much, so I can't be of help there. But the point you raised about
mv -i
(and the dry-run + undo) is good enough for me to warrant a switch. Thanks, Wei Shen!