Re: [PATCH] rename: move command from util-linux to coreutils

[Pádraig Brady]

On 05/05/2014 08:29 PM, Sami Kerola wrote:
> On 24 December 2013 22:29, Sami Kerola <address@hidden> wrote:
>> This is a resubmission[1][2] of the rename(1), with attempt to move it
>> from util-linux package to coreutils.  Various compiler warnings are
>> removed, make syntax-check passes, --test option is renamed to --dry-run,
>> file list can be wrote to stdin but only if --files0-from is in use.
>> AFAIK most of the issues mentioned earlier are sorted, and it is either
>> time to get more advice what could be improved, or final reject for the
>> proposal to move the command to this project.
>>
>> [1] http://lists.gnu.org/archive/html/coreutils/2012-06/threads.html#00021
>> [2] http://lists.gnu.org/archive/html/coreutils/2012-07/threads.html#00014
> 
> Hello coreutils maintainer(s),
> 
> It's been a while since change submission, and I guess no review is the
> same thing as final reject.  Getting a formal confirmation reject would
> be good to avoid any uncertainty which project hosts the code of the
> rename(1).

Hi Sami.

So this was first proposed nearly 3 years ago:
http://lists.gnu.org/archive/html/coreutils/2011-06/msg00080.html
There was reluctance then, which for me at least hasn't changed.
The main issue I have is that there are currently 2 existing utils
(prename and rename.ul) presented as the rename command.
Also there is the separate mmv command to provide this functionality.
So I'm not sure that adding another is worth the confusion.
Batch renaming is not really mainstream functionality anyway and
there is also the option of using find | sed | sh as mentioned previously.

If there were no existing tools for this, then we could
consider incorporating into coreutils. However given the current state
of things, I don't think it's appropriate to add to coreutils.
I'm 60:40 against.

sorry,
Pádraig.

p.s. BTW on the interface, --files0-from is used in coreutils
only when we need to process all input in a single invocation,
which is not the case here.  Also the --exec option is run
per file and thus doesn't offer a performance benefit over
separately processing the file list.