Bug#735134: perl: rename(1) is ancient

[Jay Berkenbilt]

Dominic Hargreaves <dom at earth.li> wrote:

> On Mon, Feb 03, 2014 at 09:28:03AM +0000, Jonathan Dowland wrote:
>> Hi Gregor,
>> 
>> On Sun, Feb 02, 2014 at 07:31:02PM +0100, gregor herrmann wrote:
>> > It's the package for the CPAN File::Rename distribution, and
>> > therefore named accordingly to
>> > https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names
>> > in Debian.
>> 
>> Thanks for pointing me at that. It seems to me this makes sense for
>> libraries but not for end-user binaries.
>>  
>> > (Cf. also
>> > http://pkg-perl.alioth.debian.org/policy.html#package_naming_policy )
>> 
>> This seems to agree since it suggests end-user binary packages should
>> not follow the libfoo-bar-perl scheme.
>> 
>> [ as a side-note, if the perl group are following the latter, then
>>   a minor-severity bug against policy to update the former to reflect
>>   that practise sounds like it might be in order. I'll do this unless
>>   anyone objects. ]
>> 
>> I guess there are common situations where you have both an end-user
>> binary and a perl module in the same source, and you might not want
>> to split that into two binary packages (if they're very small or 
>> something), however that doesn't appear to be the case here.
>
> Yeah, I think I agree that this package should be named 'rename' since
> it will be predominantly used as an standalone utility rather than
> library. (I'm assuming noone is going to object to such a generic name).
> I'll file a new bug for that.
>
> Thanks,
> Dominic.

Sorry to come late to the party, but I thought I'd chime in a few
points.  Feel free to disregard as they are not that important.  I
haven't read the whole thread, so hopefully I'm not covering previously
covered ground.

Back in 2004 before I was a debian developer, I was looking to package a
script I wrote called patmv.  patmv was inspired by rename perl but has
slightly different behavior.  You can find the thread about it here:

https://lists.debian.org/debian-mentors/2004/04/msg00391.html

The upshot of the discussion was that people objected to having a
package for a single script even though there seemed to be general
agreement that what it did was useful.  It was suggested at the time
that I try to get the script added to the renameutils package, but I
never pursued that.

If you would be interested in including patmv in your package or in
following up on the idea of having it included in renameutils, I can
supply patmv.  I should put it online anyway in case anyone would find
it useful.

Basically the main difference between rename and my patmv script is that
patmv keeps track of renames that it has already done and tries to
operate on the last path element unless the -w flag is given.  So, for
example, if you wanted to take an entire directory and recursively make
it lower-case, you can do that with patmv.  Here is a quick
illustration:



% mkdir -p A/B/C
% echo test > A/B/C/D
% tree
.
└── A
    └── B
        └── C
            └── D

3 directories, 1 file
% find . | rename tr/A-Z/a-z/
Can't rename ./A/B ./a/b: No such file or directory
Can't rename ./A/B/C ./a/b/c: No such file or directory
Can't rename ./A/B/C/D ./a/b/c/d: No such file or directory

Note that rename fails here because after it renames A to a, the other
files are no longer valid.  The result is that just A got renamed:

% tree
.
└── a
    └── B
        └── C
            └── D

3 directories, 1 file

patmv can do this though:

% mv a A
% find . | patmv tr/A-Z/a-z/
mv ./A ./a
mv ./a/B ./a/b
mv ./a/b/C ./a/b/c
mv ./a/b/c/D ./a/b/c/d
% tree
.
└── a
    └── b
        └── c
            └── d

3 directories, 1 file
% patmv -w s,/,.,g a/b/c/d
mv a/b/c/d a.b.c.d


Also, since patmv echoes the mv commands that it is running (unless run
with -s), you can also do stuff like

patmv -n s/\./_/g | sed -e 's/^/git /'

to generate git mv commands.  I use it this way all the time.

If anyone is interested, I will take a few minutes and stick this with
in a github repository.  I also write a manual page for it when I was
planning on packaging it.

-- 
Jay Berkenbilt <qjb at debian.org>