From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1612 invoked by alias); 5 Sep 2010 18:38:46 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 15369 Received: (qmail 9335 invoked from network); 5 Sep 2010 18:38:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <100905113823.ZM9231@torch.brasslantern.com> Date: Sun, 05 Sep 2010 11:38:23 -0700 In-reply-to: <20100901180142.56a9180f@csr.com> Comments: In reply to Peter Stephenson "Re: Bug Report: glob qualifier Lm-1 does not work" (Sep 1, 6:01pm) References: <20100901155416.GA8509@Lancelot> <20100901180142.56a9180f@csr.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Bug Report: glob qualifier Lm-1 does not work MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 1, 6:01pm, Peter Stephenson wrote: } Subject: Re: Bug Report: glob qualifier Lm-1 does not work } } In other words, files "less than 1 megabyte" have to be zero. You'll see } that it does indeed pick up files of zero size. } } The logic behind the reason is that this makes *(Lm-1), *(Lm1) and } *(Lm+1) disjunct sets, as you might naively expect (until you worked } out the implications) [...] although you might have thought it would } make more sense to round file sizes down rather than up. I seem to recall that these semantics are intended to produce the same results as the output of "find" with the same -/+ modifiers. In my zsh build tree, find . -size 2k -print print -l **/*(Lk2) both ouptut the same 62 files, and with -2 both print the same 219 other files. If not for that, it might make the most sense to round to the *nearest* size (or whatever measure) rather than up or down. E.g. right now if U is a multiplier expressed in bytes for a unit such as "megabyte" and S is a file size in bytes as read from stat(), zsh computes N = (S + (U - 1)) / U using long integers so the result is truncated. Looking for files less (or greater or equal) X units then compares N to X. But zsh could do N = (S + (U / 2)) / U and preserve the property of distinct sets while treating files less than half a megabyte in size as "less than one" megabytes. However, I'm not sure that would satisfy anyone either, because users couldd still be confused as to why three-fourths of a megabyte is not less than one. As I mentioned before, zsh instead could compare S to (X * U) without rounding or truncating at all, which is probably what most people are expecting; but then "files exactly 1 megabyte in size" becomes "too precise." Of course the ulitmate question here is, how does one express what Roy actually intended when he wrote (Lm-1), other than by writing it out longhand as (L-1048576)? (And is even that what was intended?) I think the answer is that you can't. You must choose a multiplier based on how precise a comparison you want.