Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Accessing files by inode #s
Message-ID: <41204@sun.uucp>
Date: 6 Feb 88 01:57:16 GMT
References: <11667@brl-adm.ARPA>
Sender: news@sun.uucp
Lines: 62

> However, it doesn't work in every case. I have one right now in my home
> directory which will show up in an "ls -lt" listing as "?ol?". If I do an
> "rm ?ol?" or "rm -i ?ol?", I get "rm: hold non-existent" as the response.
> An "ls -l ?ol?" will get "cannot stat hold" as the response. Notice that
> the commands can say "hold" in these cases, and not "?ol?". They CAN find
> this file, but they then cannot work upon it. An "od -c ." will
> produce output in which I can find the offending file with its name
> interpreted as "350 o l 344". 

The problem here is that most implementations of UNIX command processors
("shells") use the 8th bit of an 8-bit byte internally; they strip this bit off
in file names and other arguments to commands.  That is why the commands say
"hold"; they have been handed the file name with its 8th bit stripped off, and
if you strip the 8th bit from octal 350 you get octal 150 which is the code for
'h', and likewise for octal 344 which becomes 'd'.

So, in fact, the commands *can't* find the file; the message "cannot stat hold"
is issued because they can't find the file "hold" to stat it.

This deficiency is fixed in the System V Release 3 version of the Bourne shell,
and, I believe, in the "ksh-i" version of the Korn shell.  People have also
fixed the C shell, but you can't get it from Berkeley in that form.

> In short, I thank all those who sent me responses, but I wouldn't have
> pestered the list if something obvious like "rm -i" would have worked.

"rm -i *" won't work unless you have a shell that doesn't strip off the 8th
bit.  "rm -i ."  should work, because it will try to remove all the files in
the current directory before removing the current directory.  "rm" will get the
names of the files in that directory by itself, without the shell's assistance;
"rm" doesn't do anything with the 8th bit, so this is not a problem.  "-i"
makes it ask before removing any files; "just say no" to all questions, except
when it asks you to remove the file you want removed.

Note that "rm" will just print the file name as it sees it.  Some terminal
drivers will strip the 8th bit off, so that file's name will appear as "hold".
Others can be told not to strip this bit off; some terminals will then do it
for you, so they will display it as "hold".  Others will not; if they support
the ISO Latin #1 alphabet, they will display it as "\`eol\:a", where "\`e"
represents the letter "e" with a "`" accent above it, and "\:a" represents the
letter "a" with a diaresis or umlaut above it.

Note that the 4.2BSD and 4.3BSD file systems, as provided by Berkeley, disallow
file names containing characters with the 8th bit set.  However, as this
disallows files named e.g. "Citro\:en", where "\:e" represents the ISO Latin #1
charater that is the letter "e" with a diaresis above it, and as such file
names may be considered desirable outside the Anglophone world, many vendors
will remove this restriction.

The most common reason *I* have seen for files with "funny" names is that an
executable program for a machine other than the one on which it was run will,
most likely, be treated as a command script by the shell on that machine, since
it has its execute permission bits set.  As more systems adopt Dennis Ritchie's
"#!" convention, permitting the kernel to find a command interpreter program
that is required for executing a shell script and run that program when the
script is "exec"ed, it will be less frequently necessary to have the shells
treat any file with execute permissions as a potential shell script.  It might
be useful to have an option to the shells saying "don't run this if it has
execute permission but is not an executable image".
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com