[ On Mon, October 31, 1994 at 16:24:31 (-0500), Chris G. Demetriou wrote: ]
> Subject: Re: Little prob with rm 
>
> for files, no.  you get an error if you try to open
> /dira/dirb/dirc/file/ .

Of course, and this normally wouldn't be a problem for tcsh/ksh/zsh/etc
users, since the shell won't append a "/" to a filename expansion.

For precoded variables and such, this is a necessary error to show that
what you (once) thought was a directory is (now) actually a file.

> for directories, _NO_.  when you try to open directory:
> 
> /dira//dirb/////dirc
> 
> you are, in effect, trying to open:
> 
> /dira/./dirb/././././dirc

Which in effect is a collapse, from the user's point of view.  I was
under the impression that some UNIX versions (SysV's perhaps) actually
did collapse the multiple slashes as a minor optimization to namei().

> and when you try to open directory:
> 
> /dira/dirb/dirc/
> 
> you are, in effect, trying to open:
> 
> /dira/dirb/dirc/.

Which still gets you what you think you're getting, assuming the
filesystem still has integrity, w.r.t. the linkage of "." dir entries.

Which makes me wonder -- why doesn't rmdir(2) treat it the same?  It
isn't as if the "." in this case is the current working directory of the
process calling rmdir(2), though it does mean rmdir(2) would have to
know to back up one level to properly find and complete the removal of
the directory entry from the parent directory.

I guess it's the errno returned that's most confusing/frustrating.  I
always mutter "Of course '.' is a directory!  What did you think it
was?" and then grudgingly remove the trailing slash from the argument.

I don't think having rmdir(1) remove trailing slashes is the solution,
and I'd be happy to stick with the current behaviour if POSIX says
rmdir(2) should do as it does now.

-- 
						Greg A. Woods

+1 416 443-1734			VE3TCP		robohack!woods
Planix, Inc. <woods@planix.com>; UniForum Canada <woods@uniforum.ca>