bash：当前缀太短时，使用重命名以左填充文件名为零

Question

我使用带有数字前缀的命名约定来跟踪一些文件。但我的 2 位数前缀用完了。所以，我想搬到011.abc 012.def，而不是11.abc 12.def。我已经有一些013.xxx 014.yyy。

在空目录中尝试：

touch 11.abc 12.def 013.xxx 014.yyy

ls -1 给出：

013.xxx
014.yyy
11.abc
12.def

尝试#1：

这应该匹配任何以 2 位开头的数字，而不是 3 位。

rename -n 's/^\d\d[^\d]/0$1/' *

现在我有点希望$1 能举办比赛，就像11，0$1 给我011。

没有这样的运气：

Use of uninitialized value $1 in concatenation (.) or string at (eval 2) line 1.
'11.abc' would be renamed to '0abc'
Use of uninitialized value $1 in concatenation (.) or string at (eval 2) line 1.
'12.def' would be renamed to '0def'

从积极的方面来说，它愿意离开 013 和 014。

试试#2 rename -n 's/^\d\d[^\d]/0/' *

'11.abc' would be renamed to '0abc'
'12.def' would be renamed to '0def'

由于这是基于正则表达式的，我可以以某种方式保存匹配组 11 和 12？

如果我不能使用重命名，我可能会编写一个快速的 Python 脚本。不想在上面循环使用mv。

而且，实际上，我的命名约定是 2-3 位数字后跟一个点，所以这也是一个很好的匹配。

rename -n 's/^\d\d\./<whatever needs to go here>/' *

不管怎样，我使用的是 Homebrew 版本的重命名，就像我在 Mac 上一样。

Answer 1

rename 是有问题的，因为它不是 POSIX 的一部分（因此它在许多类 Unix 系统上通常不可用），并且有两种非常不同的形式广泛使用。请参阅Why is the rename utility on Debian/Ubuntu different than the one on other distributions, like CentOS? 了解更多信息。

此 Bash 代码使用 mv（它是 POSIX 的一部分）进行重命名：

#! /bin/bash -p

shopt -s nullglob  # Patterns that match nothing expand to nothing.

for f in [0-9][0-9].* ; do
    mv "$f" "0$f"
done

• shopt -s nullglob 是为了防止代码在没有需要重命名的文件的目录中运行时出现问题。如果nullglob 未启用，代码将尝试重命名名为“[0-9][0-9].*”的文件，无论这样的文件是否存在都会产生不良后果。

Answer 2

试试这个：

rename 's/^(\d{2}\..*)/0$1/' *