\0

[Peder Stray]

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

Requestors:

• [e-mail]

From [e-mail] 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

[Peder Stray]

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.

[Peder Stray]

From [e-mail] 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 ;-)