zsh-users
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-users@zsh.org
Subject: Re: globbing in conditional expressions
Date: Wed, 14 May 2014 00:18:19 -0700	[thread overview]
Message-ID: <140514001819.ZM23478@torch.brasslantern.com> (raw)
In-Reply-To: <20140514041908.GF2471@tarsus.local2>

On May 14,  4:19am, Daniel Shahaf wrote:
}
} > You could define (via zmodload) an operator that applies filename
} > generation to its argument, but changes to the internals of globbing
} > would be needed to make a short-circuit happen.  Then those changes
} > would have to be exposed somehow so that the operator could use them.
} 
} I've taken a shot at making those changes, see attached.

Interesting!  A few thoughts just reading through the patch:

I'm very curious why you chose to insert a new parameter in the middle
of the globlist() and zglob() signatures, instead of appending it.

The way we'd have typically done this in the past would be to keep the
old call signature as it was and introduce a new entry point with the
new signature, to isolate the changes to as few files as possible.
This also makes it easier to match meaningful changes to the commits
that made them, given that nearly all of the changes in the calls are
not changes of semantics.

(The main body of the old function would become the body for the new
call signature, to which the old signature would then call through.
On the other hand, that does lead to some clutter, so I don't really
feel that strongly either way.)

The strspn(..., "abcdefghkmnoprstuwxzLONGS") probably should NOT have
the "m" added to them, because those are intended to be identifying
operators that are defined by POSIX "test".  It'd be a bit difficult
to use [ -m ... ] anyway because the glob pattern would expand before
the call to the test builtin.

Do I read correctly that "shortcircuit" also means "don't return any
file names, just return an indication of whether there is such a file"
??  (Since you don't allocate the matchbuf array when shortcircuit.)
If so, there might be a more descriptive name for it, "search_only"
or something.

The test [[ -m zero* ]] && [[ ! -m *nonexistent* ]] could be written
[[ -m zero* && ! -m *nonexistent* ]] -- if that doesn't parse (I see
no reason to think it wouldn't) then something is wrong.  Did you
check path searches like **/zero* and whether glob flags work right?

I may give this patch a try tomorrow sometime.


  reply	other threads:[~2014-05-14  7:18 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-07 12:41 Roman Neuhauser
2014-05-07 14:44 ` Peter Stephenson
2014-05-08 10:55   ` Daniel Shahaf
2014-05-08 11:20     ` Peter Stephenson
2014-05-08 15:34       ` Bart Schaefer
2014-05-08 20:19         ` Roman Neuhauser
2014-05-13 15:41           ` Bart Schaefer
2014-05-14  4:19             ` Daniel Shahaf
2014-05-14  7:18               ` Bart Schaefer [this message]
2014-05-15  4:55                 ` Bart Schaefer
2014-05-15  9:35                   ` Daniel Shahaf
2014-05-15 14:33                     ` Bart Schaefer
2014-05-15  9:29                 ` Daniel Shahaf
2014-05-15 14:50                   ` Bart Schaefer
2014-05-26 23:52                     ` Daniel Shahaf
2014-05-30  3:59                       ` Bart Schaefer
2014-05-30  8:47                         ` Peter Stephenson
2014-05-30 15:55                           ` Bart Schaefer
2014-05-31  4:43                             ` Bart Schaefer
2014-05-31 17:34                               ` Daniel Shahaf
2014-05-31 17:59                                 ` Bart Schaefer
2014-06-02  9:40                                   ` Peter Stephenson
2014-06-02 12:57                                     ` Daniel Shahaf
2014-06-02 14:15                                       ` Peter Stephenson
2014-05-30 14:45                         ` Daniel Shahaf
2014-05-14  7:42               ` Christoph (Stucki) von Stuckrad
2014-05-14 21:09               ` Roman Neuhauser
2014-05-15  9:14                 ` Daniel Shahaf
2014-05-15 10:05                   ` Roman Neuhauser
2014-05-07 14:57 ` Mikael Magnusson
2014-05-07 15:03 ` 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=140514001819.ZM23478@torch.brasslantern.com \
    --to=schaefer@brasslantern.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).