12

I've got a slight problem with a very stubborn error during an rsync. It's caused by a file with a special character in its filename. There's been others but I could sort that out by doing some conversion in the encoding of the filename. However this one file I can't even find.

So here's what rsync says:

../.\#033OA.tex.pyD0MB" failed: No such file or directory (2)

First thing one notices is that the character code can't be hex or octal so I've googled it and only found this. So it may be a CURSOR UP character (or not). I've tried

ls -la *`printf '\033OA'`*

to no avail. I've also tried piping the output of ls of that directory to od to no avail.

What else can I do? Or what character am I looking for anyway?

Thanks

Improve this question
2
  • 1
    Try ls -b, which should show C-style escapes Commented Aug 31, 2011 at 9:28
  • thanks... that helped... could move it with the help of printf then... if you repost this comment as answer, I'll gladly accept it :) Commented Aug 31, 2011 at 10:51

2 Answers 2

Reset to default
12

You can use the -b option to ls, which shows non graphical characters as C-style escape sequences.

Improve this answer
3

ls -aq will print all file names, with a ? instead of each nonprintable character. On many unix variants, ls -AB or ls -Ab (check your man page) will print octal escapes. With ls -aq, you can use the displayed output as a shell pattern.

$ ls -Aq .?OA.tex.pyD0MB … more stuff … $ mv -i .?OA.tex.pyD0MB weird-file $ less weird-file

Another way to get at the file name somehow is to use your shell's completion: enter mv . and press Tab repeatedly until the weird name is inserted.

Improve this answer
3
  • 1
    ls -q didn't show the file whereas ls -b did. maybe because its filename wasnt [weird-character]OA.tex but really `printf %b '\033OA'`.tex Commented Sep 1, 2011 at 5:50
  • @luxifer There's a . at the beginning of the file name, so you need ls -Aq or ls -aq. And if you use shell wildcards, you need to make the . explicit: * won't include the file but .* will. Commented Sep 1, 2011 at 6:31
  • no there wasn't! The output I posted was from rsync and it was the end of the line. Rsync first copys to $DESTINATION/.$FILENAME before it moves the file to it's correct name. Therefor at the source the file had no . at the beginning of its name. Also, as said, ls -q wouldn't have shown the file whereas ls -b did. Commented Sep 5, 2011 at 6:23

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.