rename (prename) ignores -n parameter in Xenial Daily

[Andrew Oakley]

Xenial Daily with updates applied up to 2015-11-24 20:50 GMT

The perl rename function (aka prename) appears to rename files even when the -n parameter is supplied. The -n parameter is supposed to make it display possible changes, but not actually rename files (no action).

Unfortunately in the latest Xenial Daily it ignores the -n and goes ahead and renames the files.

This also applies to the long option --no-act

Example:

touch oldname
rename "s/oldname/newname/" * -n
ls

What I expected to happen:
* The command should return "oldname renamed as newname"
* The listing should show the file "oldname"

What actually happens::
* The command returns nothing
* The listing shows the file "newname"

Also note that even without the -n parameter - i.e. when I deliberately *want* to make the change - the command still does not return anything. Normally it would return "oldname renamed as newname".

perl --version shows:
This is perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-gnu-thread-multi

rename -V shows:
/usr/bin/rename using File::Rename version 0.20

I am wondering whether this is some kind of clash between the rename package and the perl package. Xenial seems to be very confused about which version of rename it has installed.

Now try the test case using the exact spelling "prename". The test case now works as expected. In previous LTS versions of Ubuntu, prename and rename were one and the same program.

Try the following:
man rename
man prename

Note the differences in parameters (e.g. --nono vs. --no-act) Both of these commands claim to be Perl rename.

In the the previous LTS version of Ubuntu, 14.04, doing man rename and man prename gave identical results. My test case above worked as expected under 14.04 .

Also note that despite the 16.04 man pages and 14.04 man pages stating that the -n parameter has to be provided *before* the expression and files, under 14.04 (and for as long as I can remember, possibly back to 6.06) it worked fine providing the -n parameter *after* the other arguments.

(I only test LTS releases. This bug may or may not have been extant in 14.10,15.04,15.10 )

Thank-you for your time examining this bug. Having a stable LTS Ubuntu is important to me; genuine thanks.

[Andrew Oakley (andrew-aoakley)]

Doing sudo apt-get remove rename seemed to solve this problem.

I am wondering whether I installed rename by mistake. Is it installed by default? If so, it shouldn't be; I believe rename is provided by Perl anyway.

[Dominic Hargreaves (dom)]

The version of rename from perl is being removed from the perl package - it was added by the Debian package and was unmaintained. rename/prename is now provided by the separate rename package, as you indicated.

The intention is that they are compatible with easy other, so I'm definitely interested if that isn't the case.

The problem you're describing (which is not specific to the newer version of rename - it appears with the old rename from the perl package too at least in my testing on Debian) is that -n is being ignored when supplied as the last argument. Both manpages specify that options must come before the expression and file list.

[Thomas Furfaro (tfurfaro)]

I had the same issue as the original reporter, and as suggested, apt- removing 'rename' reverted it back to the behavior that I had come to expect from the older version.

This problem occurred for me when upgrading from 14.04 to 16.04 via the `do-release-upgrade` tool.

I agree that the man page is 'correct', but the difference is silent and can put users in an awkward situation via making assumptions based on historic behavior.