From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c From: Charles Forsyth In-Reply-To: <200403191112.i2JBCsTK000660@adat.davidashen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Fri, 19 Mar 2004 12:31:36 +0000 Topicbox-Message-UUID: 397b819e-eacd-11e9-9e20-41e7f4b1d025 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.