zsh-users
 help / color / mirror / code / Atom feed
* Inconsistent behavior with comparisons and recursive glob patterns
@ 2024-04-30  8:14 Alan Wagner-Krankel
  2024-04-30 14:11 ` Eric Cook
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Wagner-Krankel @ 2024-04-30  8:14 UTC (permalink / raw)
  To: Zsh Users

The results of these conditional expressions using recursive glob
operators were unexpectedly different:

> [[ f0 = **/f? ]] && print true || print false
false
> setopt extendedglob
> [[ f0 = (*/)#f? ]] && print true || print false
true

Since **/ is a shorthand version of (*/)#, it seems like they both
should have returned 'true'. The comparisons behave the same when
there is at least one directory in the path:

> [[ d1/f1 = **/f? ]] && print true || print false
true
> setopt extendedglob
> [[ d1/f1 = (*/)#f? ]] && print true || print false
true

I came across this because it affects the behavior of zmv, via a test
that filters filenames (line 254 in zsh5.9). An example:

> mkdir d1 d1/d2
> touch f0 d1/f1 d1/d2/f2
> print -rl -- **/f?
d1/d2/f2
d1/f1
f0
> autoload zmv
> zmv -n '**/f?' '$f.txt'
mv -- d1/d2/f2 d1/d2/f2.txt
mv -- d1/f1 d1/f1.txt
> zmv -n '(*/)#f?' '$f.txt'
mv -- d1/d2/f2 d1/d2/f2.txt
mv -- d1/f1 d1/f1.txt
mv -- f0 f0.txt

I think both zmv calls should have attempted to update the 'f0' file
in the base directory. Am I missing something?

Thanks,
Awk


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Inconsistent behavior with comparisons and recursive glob patterns
  2024-04-30  8:14 Inconsistent behavior with comparisons and recursive glob patterns Alan Wagner-Krankel
@ 2024-04-30 14:11 ` Eric Cook
  2024-04-30 18:15   ` Bart Schaefer
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Cook @ 2024-04-30 14:11 UTC (permalink / raw)
  To: zsh-users

On 4/30/24 04:14, Alan Wagner-Krankel wrote:
> The results of these conditional expressions using recursive glob
> operators were unexpectedly different:
>
>> [[ f0 = **/f? ]] && print true || print false
> false
>> setopt extendedglob
>> [[ f0 = (*/)#f? ]] && print true || print false
> true

A couple things about [[:

```
Pattern metacharacters are active for the pattern arguments; the patterns  are
the  same  as those used for filename generation, see zshexpn(1), but there is
no special behaviour of ‘/' nor initial dots, and no glob qualifiers  are  al‐
lowed.
```

That last bit about glob qualifiers is out of date since you can now use them to
force filename generation on in [[. but the point is you aren't doing filename
generation in [[ (by default), which is where **/ is shorthand for (*/)#.
pattern matching/globbing is tightly coupled to filename generation in unix shells
but there are difference.

Even when you use a glob qualifier to force filename generation to happen, you
still wasn't going to get the behavior you desired since the pattern would've
underwent filename generation before the comparison that [['s =/== does.

% (set -x; [[ f0 = **/f?(#qN) ]]; touch f2; [[ f0 = **/f?(#qN) ]])
+zsh:3> [[ f0 =  ]]
+zsh:3> touch f2
+zsh:3> [[ f0 = f2 ]]

>
> Since **/ is a shorthand version of (*/)#, it seems like they both
> should have returned 'true'. The comparisons behave the same when
> there is at least one directory in the path:
>
>> [[ d1/f1 = **/f? ]] && print true || print false
> true
>> setopt extendedglob
>> [[ d1/f1 = (*/)#f? ]] && print true || print false
> true
>
> I came across this because it affects the behavior of zmv, via a test
> that filters filenames (line 254 in zsh5.9). An example:
>
>> mkdir d1 d1/d2
>> touch f0 d1/f1 d1/d2/f2
>> print -rl -- **/f?
> d1/d2/f2
> d1/f1
> f0
>> autoload zmv
>> zmv -n '**/f?' '$f.txt'
> mv -- d1/d2/f2 d1/d2/f2.txt
> mv -- d1/f1 d1/f1.txt
>> zmv -n '(*/)#f?' '$f.txt'
> mv -- d1/d2/f2 d1/d2/f2.txt
> mv -- d1/f1 d1/f1.txt
> mv -- f0 f0.txt
>
> I think both zmv calls should have attempted to update the 'f0' file
> in the base directory. Am I missing something?
>
> Thanks,
> Awk
>
I'll leave zmv's implementation for someone else to answer but i suspect the reasoning is similar.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Inconsistent behavior with comparisons and recursive glob patterns
  2024-04-30 14:11 ` Eric Cook
@ 2024-04-30 18:15   ` Bart Schaefer
  0 siblings, 0 replies; 3+ messages in thread
From: Bart Schaefer @ 2024-04-30 18:15 UTC (permalink / raw)
  To: zsh-users

On Tue, Apr 30, 2024 at 1:15 AM Alan Wagner-Krankel <awk@awkwork.com> wrote:
>
> > zmv -n '**/f?' '$f.txt'
> mv -- d1/d2/f2 d1/d2/f2.txt
> mv -- d1/f1 d1/f1.txt
> > zmv -n '(*/)#f?' '$f.txt'
> mv -- d1/d2/f2 d1/d2/f2.txt
> mv -- d1/f1 d1/f1.txt
> mv -- f0 f0.txt
>
> I think both zmv calls should have attempted to update the 'f0' file
> in the base directory. Am I missing something?

On Tue, Apr 30, 2024 at 7:11 AM Eric Cook <llua@gmx.com> wrote:
>
> ```
> Pattern metacharacters are active for the pattern arguments; the patterns  are
> the  same  as those used for filename generation, see zshexpn(1), but there is
> no special behaviour of ‘/' nor initial dots, and no glob qualifiers  are  al‐
> lowed.
> ```
>
> I'll leave zmv's implementation for someone else to answer but i suspect the reasoning is similar.

I suspect there's no explicit reasoning in zmv.  **/ is specifically
handled in the case of zmv -w/-W (workers/27247) but not for '$f'
placeholders.

It works if you do this:

zmv -n '(**/)f?' '$f.txt'

Whether it should also work without the parens and also without the -w
option is unclear.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-04-30 18:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-30  8:14 Inconsistent behavior with comparisons and recursive glob patterns Alan Wagner-Krankel
2024-04-30 14:11 ` Eric Cook
2024-04-30 18:15   ` Bart Schaefer

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).