Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth <forsyth@terzarima.net>]

i'm neutral about the whole thing: i think it's fine as it is,
but woudn't fret too much if glob changed.  as it happens, i discovered only last year
that roger changed Inferno's Filepat (rhymes with cow pat) four
years ago to return a result that had the names sorted and unique
(it just required invoking an option in a lower-level routine).
i probably wouldn't have done it myself (partly for reasons below), but
on a list of changes that would end the world, it's fairly low on my list,
and i doubt it would cause much more trouble in Plan 9.
in practice, though, i find it makes very little difference, and i use both systems of course.

one reason might be that (in my experience) union mounts aren't much used in the small,
so there aren't a lot of them, and those there are tend to be used
to set up a larger structure (eg, /bin, /dev, /net, service directories) or to provide limited,
judicious replacement of one thing by another.  thus, except when
initially experimenting with the mechanism on seeing the system for the first time,
or testing things after changing the implementation, i rarely interact with union
directories through the user interface or scripts to the extent that i need worry in practice
about whether pattern matching returns duplicates or not for lp (say).
thus, i don't really care too much about the duplication effect.

furthermore, if worrying about pattern matching returning duplicates for a directory,
i'd have thought in practice it might be equally troublesome for the use of lp (say) that
	lp a*
would no longer produce duplicates, which is splendid, but
	lp a* *a* q/a*.[ch] q/*.[ch]
would of course still produce duplicates in general (as a simple example to
illustrate the point, there are probably more compelling ones).
you could therefore make good use of a nodup function (as geoff suggested) in general anyhow.
(its surrounding `{} limits the scope of the nodup operation.)
thus, you could just as well use it for the special case of duplicate names
possibly produced by a union directory.

i don't think union mount is particularly good at creating variant directory
structures for software development, because of the white-out and other problems
already mentioned; for that i suspect you want a different definition of union,
more like union of whole directory trees, and it seems both better and possible
to supply that through a user-level file server that can be precisely configured,
rather than putting too much load on the existing simple bind/union operations
in the kernel that are quite effective within their own scope.