topic Re: removing odd named file containing non-printing characters in Operating System - HP-UX

removing odd named file containing non-printing characters

Paolo_c — Wed, 30 Sep 2015 09:09:57 GMT

Good morning ,

We have an odd named filename (q! ) below which was accidentally created through a VI editing session . and which we're now struggling to remove. if i list the 'filename' (inc nonprinting characters)) it displays the following

'filename'.

#ll -lsqb

-rw-r--r-- 1 root sys 540 Sep 29 15:43 \177q!

Could someone please suggest a method I could employ to safely remove (or rename) this file ?

thanks

Paul

Re: removing odd named file containing non-printing characters

Steven Schweda — Wed, 30 Sep 2015 12:17:00 GMT

   If you can tolerate a little interactivity:

      rm -i *'q!'

   If:
      ls *'q!'
shows only one file, then the "-i" isn't really needed.

> [...] (or rename) [...]

   That may harder. "mv" has a "-i" option, but (typical of UNIX) it
has different semantics. If you can find a wildcard expression which
catches only the target file, then it's easy.

Re: removing odd named file containing non-printing characters

RJHall — Wed, 30 Sep 2015 21:45:07 GMT

Another approach is to delete by inode number:

ls -li *q!

4739 ...

then use find to locate the file by inode number and perform the rm:

find . -inum 4739 -exec rm -i {} \;

Re: removing odd named file containing non-printing characters

Dennis Handly — Thu, 01 Oct 2015 06:40:14 GMT

>-rw-r--r-- 1 root sys 540 Sep 29 15:43 \177q!

This is a Del char. So you can simply type: rm -i ?q!

And hopefully there is only one.

Or you could use tr(1) to get that Del:

$ rm -i $(echo "Aq!" | tr "A" '\177')

$ mv $(echo "Aq!" | tr "A" '\177') bad_file

Or look at the tag cloud:

http://h30499.www3.hp.com/t5/tag/unprintable%20chars/tg-p/category-id/operating_systems

Re: removing odd named file containing non-printing characters

Paolo_c — Thu, 01 Oct 2015 14:33:00 GMT

many thanks for the feedback provided. I didn't realise that this was a DEL char but the workaround provided worked fine. thanks also to everyone else that provided feedback.