zsh-users
 help / color / mirror / code / Atom feed
From: Peter Stephenson <Peter.Stephenson@csr.com>
To: zsh-users@zsh.org
Subject: Re: Bug Report: glob qualifier Lm-1 does not work
Date: Wed, 1 Sep 2010 18:01:42 +0100	[thread overview]
Message-ID: <20100901180142.56a9180f@csr.com> (raw)
In-Reply-To: <20100901155416.GA8509@Lancelot>

On Wed, 1 Sep 2010 23:54:16 +0800
Roy Zuo <roylzuo@gmail.com> 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.

(Basically Bart's answer, but I added a bit more so I'll send it anyway.)

It does do what it's intended to, it just doesn't do what you expect (and
what it's intended to do is quite confusing if you don't know what's behind
it).  Something similar came up recently; as a minimum the doc could do
with updating.  This comment on times is also relevant to sizes:

  Any  fractional  part  of the difference between the access time
  and the current part in the appropriate units is ignored in  the
  comparison.   For  instance,  ‘echo  *(ah-5)’  would  echo files
  accessed within the last five hours, while ‘echo *(ah+5)’  would
  echo  files  accessed  at least six hours ago, as times strictly
  between five and six hours are treated as five hours.

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 reason for this bizarre behaviour is that the same file size is used
when testing for less than, equal to, or greater than the requested
number.  Hence *(Lm1) picks up all those files you expect to see --- the
files that are 1 megabyte in size, ignoring the fractional part in the
difference.

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).  In other words, if you sort files into the three sets
you're guaranteed to get all files exactly once.  That's quite a useful
property, although you might have thought it would make more sense to round
file sizes down rather than up.  If it did, I think it would be much more
natural and you could probably guess that files "greater than 1 MB" needed
to be 2 MB or more without having to read the instructions.

It wouldn't be hard to add the other behaviour (rounding up), but I'm not
sure how to control it: an option (on or off by default?), or alternative
syntax (for which unfortunately < and > aren't available which is probably
why it's currently - and +)?

Index: Doc/Zsh/expn.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/expn.yo,v
retrieving revision 1.118
diff -p -u -r1.118 expn.yo
--- Doc/Zsh/expn.yo	22 Aug 2010 20:08:57 -0000	1.118
+++ Doc/Zsh/expn.yo	1 Sep 2010 16:56:18 -0000
@@ -2302,10 +2302,17 @@ time.
 )
 item(tt(L)[tt(PLUS())|tt(-)]var(n))(
 files less than var(n) bytes (tt(-)), more than var(n) bytes (tt(PLUS())), or
-exactly var(n) bytes in length. If this flag is directly followed by a `tt(k)'
-(`tt(K)'), `tt(m)' (`tt(M)'), or `tt(p)' (`tt(P)') (e.g. `tt(Lk-50)')
-the check is performed with kilobytes, megabytes, or blocks (of 512 bytes)
-instead.
+exactly var(n) bytes in length.
+
+If this flag is directly followed by a `tt(k)' (`tt(K)'), `tt(m)'
+(`tt(M)'), or `tt(p)' (`tt(P)') (e.g. `tt(Lk-50)') the check is performed
+with kilobytes, megabytes, or blocks (of 512 bytes) instead.  In this
+case a file is regarded as "exactly" the size if the file size rounded up
+to the next unit is equal to the test size.  Hence `tt(*LPAR()Lm1+RPAR())'
+matches files from 1 byte up to 1 Megabyte inclusive.  Note also that
+the set of files "less than" the test size only includes files that would
+not match the equality test; hence `tt(*LPAR()Lm-1+RPAR())' only matches
+files of zero size.
 )
 item(tt(^))(
 negates all qualifiers following it

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom


  parent reply	other threads:[~2010-09-01 17:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-01 15:54 Roy Zuo
2010-09-01 16:16 ` Jérémie Roquet
2010-09-01 16:38   ` Roy Zuo
2010-09-01 16:36 ` Bart Schaefer
2010-09-01 17:01 ` Peter Stephenson [this message]
2010-09-05 18:38   ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100901180142.56a9180f@csr.com \
    --to=peter.stephenson@csr.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).