Re: es bug

[David McNab <mcnab@nas.nasa.gov>]

On the "*/" discussion with Tom Tromey:

|Let's forget all about "ls".  I don't think it really comes into play
|here in any way.  Let's also forget about rmdir.

Well actually I can't forget about rmdir(1), because it's
the problem.

Let me first say that I was wrong about rmdir(1) and the
trailing "/".  rmdir(1) accepts the trailing slash because
it passes its arguments (eventually) to namei(), which
ignores extraneous "/" characters where they don't matter.
That's why if "/tmp/foo" is a directory you can refer to it
as "/tmp/foo/" or even "//tmp//foo//".

|There are two things I don't undertsand:
|
|1. Why "foo/" is not the same as "foo/.".  After all, "" is the same
|   as ".".  But I don't expect to get any real answer to this, and I
|   don't think it falls into es' domain anyway.

They are the same thing, sort of.  The kernel resolves
pathnames using the namei() routine, which returns an
inumber for the specified path.  So:

  namei("/foo") == namei("/foo/.") == namei("//tmp/foo/")

The "*/." solution is the elegant and correct solution in
almost all cases, because most system calls (the eventual
recipients of the pathnames specified on the command line)
use namei() to resolve the pathname to an inode.  Hence
"foo/" and "foo" and "foo/." are identical.  Except that to
rmdir(2) they are not.

Actually this is quite interesting in a pedantic way.
rmdir(2) prevents you from removing "the '.' entry of a
directory".  This implies that rather than simply calling
namei() to resolve the pathname and then unlinking the
directory entry, rmdir(2) is doing its own check on the
path (otherwise it wouldn't know you were trying to remove
the "." entry).

I don't know why rmdir(2) would want to do this.  Of course
it also prevents you from removing your current directory,
which doesn't make sense either -- if I can remove someone
else's current directory why can't I remove my own?  As far
as I can tell the grad student who implemented rmdir(2) at
Berkeley botched it up.  

I'm guessing that both pieces of strangeness have something
to do with supporting networked file systems.  If anyone's
interested I'll try and find out.

|2. Why the expansion of "*/" is not a bug any way you look at it.
|   There are two cases: on my machine, "*/" expands into what is
|   clearly garbage (aside: the example you give does do the right
|   thing -- it expands to "h*").  Case 2: on your machine, "*/"
|   presumably expands to "*/".  Isn't this inconsistency bothersome?

What inconsistency?

; cd /tmp; mkdir foo; cd foo; mkdir x y; touch a b; ls -F
a   b   x/   y/
; echo *h
*h
; echo */
*/
;

Looks consistent to me.  Not very helpful, mind you, but
consistent.

Neither case is very satisfying, though.

Sorry to squander all this bandwidth.  I'll shut up now.

David McNab
Parallel Systems Support
CSC at NAS, NASA/Ames