Bug#885103: rename: "-n" option is ignored

[Peter De Wachter]

Hello Dominic,

[Resending with bugs.debian.org in Cc]

I feel that in Debian the expected behavior is that options and other
arguments can be mixed. Sure, no program bothers explicitly
documenting that, but why would they? It's simply the normal behavior
of glibc's getopt(3) after all. Programs that don't allow this are
exceptions.

Given that the previous version of rename allowed this and given that
it's expected behavior on Debian, I feel that this is a valid bug.

If on the other hand you really don't want to support this, I feel
it's necessary to give an explicit error message in this situation
("fatal: option -n must come before non-option arguments").

Best regards,
Peter


On Sun, Dec 24, 2017 at 8:49 PM, Dominic Hargreaves <dom at earth.li> wrote:
> On Sat, Dec 23, 2017 at 09:02:04PM +0100, Peter De Wachter wrote:
>> Package: rename
>> Version: 0.20-6
>> Severity: important
>>
>> rename ignores the '-n' option if it's not specified first on the command line:
>>
>> $ touch a
>> $ rename s/a/b/ -n a
>> $ ls -l a
>> ls: cannot access 'a': No such file or directory
>>
>> This is different from how the 'rename' command behaves in Debian stable.
>
> The implementation has changed, but the documented use of rename in
> Debian has always been that -n should be provided before the file list.
> I don't see us changing the behaviour of the new implementation to
> support these undocumented calling semantics.
>
> Best,
> Dominic.