From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 15 Jan 2012 17:18:31 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20120115161831.GA624@polynum.com> References: <20120114080106.GA807@polynum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: [9fans] du vs. ls: duplication or not? Topicbox-Message-UUID: 5ca90272-ead7-11e9-9d60-3106f5b1d025 On Sat, Jan 14, 2012 at 09:20:51AM +0000, Charles Forsyth wrote: >[...] On Linux, I > never use ls -R, partly because I'm > running p9p's ls, but mainly because the default format of /bin/ls -R is > amazingly useless (even worse than I remembered). I wasn't refering to whatever implementation (I don't use ls -R either since the output is simply not parsable). I was simply using -R, since -r is already taken. What I meant was the size of the file is already given via ls(1). So a recursive output that make sense and fit a manipulation via join(1) (to combine a srv/qid) and sort and uniq etc. could do the trick. Since ls(1) gives the size of the file; since du(1) can not really or at least not always in an arbitrary context tells the "real" occupation of disk size, is not ls(1) enough? -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C