From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <405B0000.8070509@swtch.com> From: Russ Cox User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 MIME-Version: 1.0 To: 9fans@cse.psu.edu Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c References: <50440c6f4b6946137968d772dcf08a2a@hamnavoe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Mar 2004 09:13:20 -0500 Topicbox-Message-UUID: 399a34c2-eacd-11e9-9e20-41e7f4b1d025 Rob Pike wrote: > are you planning to change the other shells too? what about every > other program > that reads directories? what does '*' really mean? you're making > assumptions > about what's right and i don't think it's clear what's right and when > things aren't > clear i say leave them alone until they clear up. after something like > 15 years > they still haven't cleared up. > > i'm not saying the behavior is right, but i'm not admitting it's > wrong, either. > moreover, i can explain everything that's going on by applying a very > simple > model that is clear from the documentation. that's worth a lot. continuing this... note how much more complicated the model gets if rc and ls (or perhaps dirreadall) start removing duplicates from the list. right now, it took you no time at all to find the existence of duplicates, and then once you realize they exist, you notice them everywhere. if the bulk of directory-processing programs remove duplicates for themselves, then some day you run across a program that doesn't (either out of neglect or because it doesn't fit the way the program does directory processing). now you know duplicates exist again. but nothing makes sense -- why haven't you noticed before? why do some programs show them and others not? the explanation isn't simple or regular or predictable -- some do, some don't, depending on their code. i'd rather live in the first world, where all programs agree. the alternate universe, where illusions come and go depending on the program, where shortcomings of the kernel are fixed by hacking around them in user space, it's a terrible way to live. if you want modern unix, you know where to find it. the clearest example i can think of in modern unix where this happens is the handling of .. by shells in order to make symlinks look not like symlinks, while the kernel is still broken, as rob points out in http://plan9.bell-labs.com/sys/doc/lexnames.pdf. there are plenty of others. russ p.s. amusingly enough, now we've filled in all the context necessary to read boyd's first post in this thread, where he posted that url and nothing else!