[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: es bug



Tom (tromey@busco.lanl.gov) wrote:
|First, this isn't what happens.  Here is an example:
|
|; cd /tmp
|; mkdir z
|; cd z
|; mkdir x y
|; touch a b
|; echo */
|a/ b/ x/ y/
|; 

Not on my machine.  Maybe your es(1) is expanding the "*" to
all the file names in the directory, treating the expansion
as a list, and appending the "/".  If you type echo h* in
that directory do you get "ha hb hx hy" as output?

|Second, I don't think of the "/" as the thing that is printed by ls
|-F.  I think of it as a valid character in a directory name.  I know
|this doesn't work on all systems, but on my Sun I can type "rmdir f/",
|and the directory will be removed.  (note that "rmdir */." doesn't
|work).

You can think of it that way, but you are not being precise.
You are confusing a psuedo-convention with "reality".  If
you opendir() the directory and read it there will be no
trailing "/" characters.  If you type "echo *" or "/bin/ls"
there will be no trailing "/", or "@" for symbolic links, or
"=" for UNIX domain sockets.

The fact that rmdir(1) recognizes "f/" as a filename is an
artifact of rmdir(1)'s parsing of its arguments, probably
originating in its developers using csh(1) and wanting to be
able to remove directories by doing things like "rmdir */".

|Third, the "a/" and "b/" values are completely bogus.  Is there any
|other case where globbing yields completely invalid results?  I don't
|think so.

Yes, in the case where csh considers "/" to be part of a
filename. :-)

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