Re: es bug

[tromey@busco.lanl.gov (Tom Tromey)]

>>>>> "David" == David McNab <mcnab@nas.nasa.gov> writes:

Tom (tromey@busco.lanl.gov) wrote:
|I've noticed that "*/" expands to all file names with "/" appended,
|instead of just the names of directories.  I think this is a bug --
|all the other glob code I've used does the right thing (expands to
|just directories).

David> I don't think this is a bug.  The suffixes that ls(1) adds when
David> -F is turned on -- for example "/" for a directory -- are not
David> part of the file names, they're just shorthand to help one read
David> a directory listing.  Since there is no file "*/" in the
David> directory, es(1) doesn't expand the "*".  Same thing happens if
David> you type "echo h*t" and there is no file matching "h*t" -- you
David> get "h*t" echoed back.

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/
; 

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).

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.

Several people have written back to me saying that I should use "*/."
instaed.  I know about that solution, I just don't like it.  For one
thing, it doesn't really work the same way -- see the "rmdir" above.

I think that globbing should either return a list of valid file names,
or it should return the original string.  Either would be preferable
to the current behavior.

Tom
---
tromey@busco.lanl.gov             Member, League for Programming Freedom
Sadism and farce are always inexplicably linked.
	-- Alexander Theroux