Tool:brename: safely batch renaming files/directories via regular expression

Question

[shenwei356]

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:

1. Brename supports dry run, by showing which files are going to be renamed and what the new names are. This makes users feel safe.
2. Besides, it detects potential overwriting conflicts before renaming, which helps avoid overwriting important files like raw FASTQ reads.
3. 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.

[Ram]

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 to rm -iv and mv to mv -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?

[shenwei356]

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.

read_1.fq.gz
read_2.fq.gz

For mv, you may use a loop for batch renaming.

1. 1th round, renaming read_1.fq.gz to read.fq.gz. It's OK, no conflict.
2. 2nd round, renaming read_2.fq.gz to read.fq.gz. Hmm, looks OK for mv -i. But it actually overwrites the newly renamed file.

Look how brename does:

$ brename -p '_\d' 
[INFO] main options:
[INFO]   ignore case: false
[INFO]   search pattern: _\d
[INFO]   include filters: .
[INFO]   search paths: ./
[INFO] 
[INFO] checking: [ ok ] 'read_1.fq.gz' -> 'read.fq.gz'
[ERRO] checking: [ overwriting newly renamed path ] 'read_2.fq.gz' -> 'read.fq.gz'
[ERRO] 1 potential error(s) detected, please check

BTW, I want to test rename, but it seems to not recognize regular expressions???

# nothing shown
rename '_\d' '' *.fq.gz -n --verbose
rename 's/_\d//'  *.fq.gz -n --verbose

[Ram]

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!