Bug#885103: rename: "-n" option is ignored
Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=124421
On Sun, Dec 24, 2017 at 09:36:59PM +0100, Peter De Wachter wrote:
> 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").
Hi,
It's a fair point. I've proposed a change upstream:
https://rt.cpan.org/Ticket/Display.html?id=124421
Cheers,
Dominic.
Bug#885103: rename: "-n" option is ignored
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 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.
Bug#885103: rename: "-n" option is ignored
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.
Bug#885103: rename: "-n" option is ignored
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. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rename depends on: ii perl 5.26.1-3 rename recommends no packages. rename suggests no packages. -- no debconf information
