Bug#960624: rename bug
Dominic Hargreaves
dom at earth.li
Sun May 17 17:50:00 BST 2020
Control: tags -1 + wontfix
On Thu, May 14, 2020 at 08:55:37PM +0200, ml at ft-c.de wrote:
> The rename command doesn't work from another directory, when there is a "^"
> (beginn-line) in the regular-expression.
>
> # script beginn ----- ----- ----- ----- -----
> $ uname -a
> Linux ftd2 4.15.0-3-amd64 #1 SMP Debian 4.15.17-1 (2018-04-19) x86_64
> GNU/Linux
> $ rename -V
> /usr/bin/rename using File::Rename version 1.10
>
> $ mkdir test
> $ cd test/
> /test$ touch Film-filmtitle1.txt
> /test$ cd ..
> $ mkdir test2
> $ cd test2
>
> /test2$ rename -v -e 's/^Film-//eg' ~/skripte/test/*
>
> /test2$ ls -l ~/skripte/test/*
> -rw-r--r-- 1 ft ft 0 Mai 12 00:48 /...../test/Film-filmtitle1.txt
>
> /test2$ cd ../test
>
> /test$ rename -v -e 's/^Film-//eg' *
> Use of uninitialized value in substitution iterator at (eval 8) line 1.
> Film-filmtitle1.txt renamed as filmtitle1.txt
>
> /test$ ls -l *
> -rw-r--r-- 1 ft ft 0 Mai 12 00:48 filmtitle1.txt
>
> # script end ----- ----- ----- ----- -----
>
> In the script, the first rename command have no result/output,
> the second rename command there is a result.
This is as I would expect; the tool takes the filenames passed to it
as input, so ^ matches the start of the whole path. I can see that
a different behaviour would be convenient in many cases, but it would
also be a breaking change to the interface, so it's not a change that
we could make without it being protected by a flag.
Quoting from the manpage, this seems fairly clear:
"rename" renames the filenames supplied according to the rule specified
as the first argument
If you are interested in taking this forward as a feature proposal, this
is something that should be done upstream - by filing a bug here:
<https://rt.cpan.org/Public/Bug/Report.html?Queue=File-Rename>. However
it would change the nature of the program, and I'm not at all sure that
the author would want to pursue this. Instead, you could consider
writing a regular expression that actually matches what you want - to
match 'Film' appearing after the final '/' - or, for simplicity, after
any '/'?
Cheers
Dominic
More information about the pkg-perl-maintainers
mailing list