From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22585 invoked by alias); 1 Sep 2010 16:36:55 -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: 15348 Received: (qmail 14648 invoked from network); 1 Sep 2010 16:36:51 -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: <100901093637.ZM9957@torch.brasslantern.com> Date: Wed, 01 Sep 2010 09:36:36 -0700 In-reply-to: <20100901155416.GA8509@Lancelot> Comments: In reply to Roy Zuo "Bug Report: glob qualifier Lm-1 does not work" (Sep 1, 11:54pm) References: <20100901155416.GA8509@Lancelot> 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, 11:54pm, Roy Zuo wrote: } } Some one just tells me that glob qualifier Lm-1 in zsh does not work, and I } can confirm it is true. Whenever you do } } ls *(Lm-1) } } it complains "no matches found". Lm+1, Lk-1024, Lk-1, Lm-2 all work well. The } only thing that does not work is Lm-1. I think something related to this was discussed quite recently ... it's a question of (a) rounding error and (b) using absolute less/greater comparisons rather than <= or >=. The comparison is made by scaling the size of the file (read from the filesystem) *down* rather than by multiplying the target units *up*, so any non-zero-sized file is always treated as at having size at least one, no matter what the scale. And L-1 only matches files having size smaller than 1, which means that it is semantically the same as L0, even with k or m inserted. The same effect should occur for every other scaling factor, but the smaller the scaling factor the fewer files are likely to be affected, so probably you just don't notice. That comparison has been that way ever since zsh existed; I don't know why it was decided to do division on the file size rather than to do multiplication on the units, other than perhaps to avoid integer overflow when searching for very big files.