zsh-users
 help / color / mirror / code / Atom feed
From: "Daniel Shahaf" <d.s@daniel.shahaf.name>
To: zsh-users@zsh.org
Subject: Re: zsh expansion fails if nocaseglob and not all directory components are listable
Date: Mon, 22 Aug 2022 19:05:17 +0000	[thread overview]
Message-ID: <b1fafe59-bd08-4058-933b-74cb3c6a4525@www.fastmail.com> (raw)
In-Reply-To: <b2e9d528-62e2-6d0e-9d14-03128cdb5110@googlemail.com>

Oliver Freyermuth wrote on Mon, 22 Aug 2022 18:02 +00:00:
> 1) Prepare directory:
>
> mkdir foo
> chmod 711 foo
> mkdir foo/test
> sudo chown root:root foo
> cd foo/test
> setopt nocaseglob
> echo $(pwd)(N)
>
> => No output is returned.
>

If the (N) is changed to (|) [that's an empty alternation], one gets
a "no matches found" error.

> Of course, zsh can not exclude there are other directories directly 
> inside "foo/" matching the given pattern (but with different case) 
> since "foo/" can not be listed. However, at least the explicit match 
> with case is known,
> so I'm astonished zero matches are returned.
>
> Is this expected, or a bug?

What would you have it do instead?

  Emit just one path?  I don't think this would work, because if the
  glob expands at all, users may rely on what it _didn't_ expand to.
  It's perfectly within the API promise for a user to set NO_CASE_GLOB
  and then rely on something along the lines of the lines of «if print -l
  /etc(|) | grep -q /ETC; then …» (note that grep(1) is case-sensitive
  in this case).

  For comparison, consider «*(u.jrandom.)» and assume a single file in
  the directory returned -1 from stat(2) (so owner uid isn't known).
  Would it be okay to just elide that file from the glob's expansion?

- Error out hard?  NULL_GLOB is typically used to mean "Treat a glob
  with zero matches the same way as any other glob", and this case is
  rather "We couldn't determine the number of matches", so, maybe?

- Enumerate all paths that compare case-insensitively equal to
  a different path and expand the glob as in the non-0711 case?  Even
  assuming ASCII English this is O(2**N) in the length of the path
  (e.g., "test" is length 4 and has 2**4 possibilities), so, not tractable.

Could be that I'm missing something, of course…

Daniel


  reply	other threads:[~2022-08-22 19:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22 18:02 Oliver Freyermuth
2022-08-22 19:05 ` Daniel Shahaf [this message]
2022-08-22 20:14 ` Lawrence Velázquez
2022-08-22 20:59   ` Bart Schaefer
2022-08-22 21:36     ` Oliver Freyermuth
2022-08-22 21:56       ` Dominik Vogt
2022-08-22 22:01         ` Oliver Freyermuth

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=b1fafe59-bd08-4058-933b-74cb3c6a4525@www.fastmail.com \
    --to=d.s@daniel.shahaf.name \
    --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).