Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!wuarchive!emory!mephisto!mcnc!rti!dg-rtp!dg-rtp.dg.com!eliot
From: eliot@dg-rtp.dg.com (Topher Eliot)
Newsgroups: comp.unix.admin
Subject: Re: help removing a file
Message-ID: <1990Sep6.163646.17499@dg-rtp.dg.com>
Date: 6 Sep 90 16:36:46 GMT
References: <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu>
Sender: usenet@dg-rtp.dg.com (Usenet Administration)
Reply-To: eliot@dg-rtp.dg.com
Distribution: usa
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 32

In article <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu>,
harmon@function.mps.ohio-state.edu (Jim Harmon) writes:
|> Could someone someone help me with removing a file. ...
|> I even tried doing `rm -i *` and it matches
|> zhangNevai.tex but says there's No such file or directory.

If 'rm -i *' fails, it is a bad one indeed.

This is just a guess, but perhaps the file name on disk has the high
(8th) bit on.  If this is the case, and the rm code is turning that
bit off somewhere, then that would explain why rm would find the file
and then not be able to unlink it.  Or perhaps the shell is expanding
the '*', but then turning off the 8th bit before passing it to rm.
Can you try 'rm -Ri .'?

You might have to write a little C program just to unlink it, that
passes a filename to the unlink system call without doing anything
that would cause the 8th bit of any of the characters to be turned off.

As I recall, some versions of ls have an option to print the weird
characters in file names as they really are, rather than turning them
into '?'.  If yours does, you could run such an ls command, and pipe
it through 'od -xc' to see what the character is.

Hope this helps.
--
Topher Eliot
Data General Corporation                eliot@dg-rtp.dg.com
62 T. W. Alexander Drive               
{backbone}!mcnc!rti!dg-rtp!eliot
Research Triangle Park, NC 27709        (919) 248-6371
Obviously, I speak for myself, not for DG.