From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <96e06cebf14ac0ed02a5390ac3dd1dbf@swtch.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] ls, rc question From: rsc@swtch.com In-Reply-To: <200403182300.i2IN0p5T095713@adat.davidashen.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-eiurptqanheavukftrazbnnkwq" Date: Thu, 18 Mar 2004 22:41:39 -0500 Topicbox-Message-UUID: 3781bc46-eacd-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-eiurptqanheavukftrazbnnkwq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit if you want, you can think of this as a bug in read(2): if a file is covered up, it should be completely hidden. it turns out that actually implementing this is quite hard, that it doesn't really break much (you've found about all of it!) to leave it as is, and that it results in things like /bin/ls giving interesting information about the union. --upas-eiurptqanheavukftrazbnnkwq Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> X-Original-To: rsc@swtch.com Delivered-To: rsc@morphisms.net Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by holo.morphisms.net (Postfix) with ESMTP id 7201A24FE8 for ; Thu, 18 Mar 2004 18:04:57 -0500 (EST) Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Mar 18 18:04:47 EST 2004 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Mar 18 18:04:44 EST 2004 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 570F419AE5; Thu, 18 Mar 2004 18:04:27 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 8E3E919C84; Thu, 18 Mar 2004 18:04:22 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 3F09119C80; Thu, 18 Mar 2004 18:03:08 -0500 (EST) Received: from adat.davidashen.net (unknown [217.113.20.242]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 64A7019AE5 for <9fans@cse.psu.edu>; Thu, 18 Mar 2004 18:03:00 -0500 (EST) Received: from adat.davidashen.net (localhost.davidashen.net [127.0.0.1]) by adat.davidashen.net (8.12.8p1/8.12.8) with ESMTP id i2IN0p7b095714 for <9fans@cse.psu.edu>; Fri, 19 Mar 2004 03:00:51 +0400 (AMT) (envelope-from dvd@adat.davidashen.net) Received: (from dvd@localhost) by adat.davidashen.net (8.12.8p1/8.12.8/Submit) id i2IN0p5T095713 for 9fans@cse.psu.edu; Fri, 19 Mar 2004 03:00:51 +0400 (AMT) From: David Tolpin Message-Id: <200403182300.i2IN0p5T095713@adat.davidashen.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] ls, rc question In-Reply-To: <405A1D45.9030400@swtch.com> Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Fri, 19 Mar 2004 03:00:51 +0400 (AMT) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Level: I am not asking why there are two file names in the directory listing. I understand it. I think that behaviours of rc and ls are confusing. I would either expect rc's globbing to only match one path name, or ls to display all files. man rc says 'A pattern is replaced by a list of arguments, one for each path name matched'. Not for each directory entry. For each path name. There is one path name /dev/user for two files. cpu% ls -q /dev|grep user (0000000000000015 0 00) /dev/user (000000000000000c 0 00) /dev/user Globbing expands this to two elements: cpu% echo /dev/user* /dev/user /dev/user I think this is not what the manual says. Then, cpu% ls -q /dev/user* (0000000000000015 0 00) /dev/user (0000000000000015 0 00) /dev/user I understand why it is so. But I think that consistency is sacrificed for simplicity. Either rc should do what the manual says and return one match for /dev/user* (so that /dev/user* and /dev/user is the same thing), or ls -q /dev/user should recursively list all directory entries matching the path name. David Tolpin --upas-eiurptqanheavukftrazbnnkwq--