\0

[pstray]

Migrated from rt.cpan.org #110028 (status was 'open')

Requestors:

• glen.mevel@crans.org

From glen.mevel@crans.org on 2015-12-02 23:07:38:

hello,

i had an unexpected (and quite annoying, as i lost a big dataset) behaviour with (perl-)rename 1.9 (both the one packaged for Archlinux and the one found at http://search.cpan.org/~pederst/rename/, which are identical saved from two lines), when using a \0 back-reference.

$ uname -a
    Linux hal 4.2.3-1-ARCH #1 SMP PREEMPT
    Sat Oct 3 19:08:23 CEST 2015 i686 GNU/Linux
$ perl -v
    This is perl 5, version 22, subversion 0 (v5.22.0)
    built for i686-linux-thread-multi
$ pacman -Ss perl-rename
    community/perl-rename 1.9-1 [installé]
$ echo this is aa > aa
$ echo this is bb > bb
$ ls |sed 's/^./x\0/'
  # this is what is commonly expected
    xaa
    xbb
$ perl-rename -v 's/^./x\0/' *
  # this is what perl-rename claims to do
  # (wrong w·r·t· what precedes) …
    aa -> xa
    bb -> xb
$ ls
  # … and this is what it really does (wrong anyway!)
    x
$ cat x
    this is bb

-- regards, Glen Mével

[pstray]

First of all, \0 is not a backreference in perl as it is in sed, it is the NUL character, chr(0).

The output from "rename -v 's/^./x\0/' * -n | hexdump -C" show this, and as you can see, you renamed your files to 'x\0a' and 'x\0b', but as a \0 cant be part of a filename, that means you renamed both files to just 'x'

00000000  61 61 20 2d 3e 20 78 00  61 0a 62 62 20 2d 3e 20  |aa -> x.a.bb -> |
00000010  78 00 62 0a                                       |x.b.|
00000014

If you had used -i with rename, it would have asked you to overwrite:

$rename -v 's/^./x\0/' * -i
aa -> xa
rename: replace `xb'? 

And as such, rename has done exactly what you asked it to do.

[pstray]

From glen.mevel@crans.org on 2015-12-04 12:16:03:

Le 04/12/2015 00:00, Peder Stray via RT a écrit :

First of all, \0 is not a backreference in perl as it is in sed, it is the NUL character, chr(0).

oh, i understand better then. i am not really familiar to Perl, so i did not bet \0 to actually mean what in means to sed. what leads me to think there was a bug anyway was the difference between the display and the actual operation.

but as a \0 cant be part of a filename, that means you renamed both files to just 'x'

maybe it would be adequate to warn the user when trying to use such forbidden characters, to avoid bad suprises of this kind? and/or adjust the display so it corresponds exactly to what is performed?

If you had used -i with rename, it would have asked you to overwrite

my bad, i just forgot that one (i usually have aliases for this)

p·s·: my misadventure was more fear than harm, since i managed to rescue the files with extundelete ;-)