strange glob expansion

strange glob expansion

[Hubert Canon]

Hi,

I tried something like this :

% echo .scwm/(chan*|**/scwmrc*) 
.scwm/0.9 .scwm/0.99.1-cvs .scwm/0.99.2 .scwm/change-scwmrc .scwm/sav .scwm/scratch

But I expected that :

.scwm/0.9/scwmrc .scwm/0.99.1-cvs/scwmrc .scwm/0.99.1-cvs/scwmrc.debug .scwm/0.99.2/scwmrc .scwm/change-scwmrc .scwm/sav/scwmrc .scwm/sav/scwmrc.sav .scwm/scratch/scwmrc-scratch

Because :

% echo .scwm/**/scwmrc*  
.scwm/0.9/scwmrc .scwm/0.99.1-cvs/scwmrc .scwm/0.99.1-cvs/scwmrc.debug .scwm/0.99.2/scwmrc .scwm/sav/scwmrc .scwm/sav/scwmrc.sav .scwm/scratch/scwmrc-scratch

What's wrong ? Did I misunderstand something ?

This one is strange too :

% echo (.scwm/**/scwmrc*|.scwm/chan*)
.scwm

Re: strange glob expansion

[Bart Schaefer]

On Sep 1, 10:11am, Hubert Canon wrote:
} Subject: strange glob expansion
}
} I tried something like this :
} 
} % echo .scwm/(chan*|**/scwmrc*)

Directory separators can't be used inside parentheses.  Parenthesized
patterns match within one level of file hierarchy only.  (The '/' may
still be useful when matching against strings, as in a `case' label, but
doesn't work when globbing.)

Since ** matches in the current directory as well as in subdirectories,
what you really wanted was

% echo .scwm/**/(chan*|scwmrc*)

Or perhaps

% echo .scwm/{chan*,**/scwmrc*}

Or maybe (if you have extendedglob set)

% echo .scwm/**/(chan*|scwmrc*)~*/*/chan*

Where the trailing bit with the tilde excludes files that match chan* in
subdirectories.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: strange glob expansion

[Hubert Canon]

Bart Schaefer écrivait :
> On Sep 1, 10:11am, Hubert Canon wrote:
> } % echo .scwm/(chan*|**/scwmrc*)
> 
> Directory separators can't be used inside parentheses.

I didn't know that. Thank you.

> % echo .scwm/**/(chan*|scwmrc*)

Yes, it works.

> % echo .scwm/{chan*,**/scwmrc*}

Not exactly. The { , } construct is somewhat different than ( | ) :
for example, when one of the partterns fails, the whole expression
fails.

Like :

% echo (foo*|bar*)
foo
% echo {foo*,bar*}
zsh: no matches found: bar*

The { , } construct always expands its components : echo {foo*,bar*}
is exatcly the same as : echo foo* bar*

That's why I prefer ( | ) in general ofr globbing.

-- 
Hubert Canon

Re: strange glob expansion

[Bart Schaefer]

On Sep 2, 12:15pm, Hubert Canon wrote:
} Subject: Re: strange glob expansion
}
} Bart Schaefer écrivait :
} > % echo .scwm/{chan*,**/scwmrc*}
} 
} Not exactly. The { , } construct is somewhat different than ( | ) :
} for example, when one of the partterns fails, the whole expression
} fails.

That's what `setopt cshnullglob` is for.  I can't imagine why anyone would
not want that option when the shell is interactive; brace expansion is
practically useless without it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: strange glob expansion

[dado]

Bart Schaefer wrote:

> On Sep 2, 12:15pm, Hubert Canon wrote:
> } Subject: Re: strange glob expansion
> }
> } Bart Schaefer écrivait :
> } > % echo .scwm/{chan*,**/scwmrc*}
> }
> } Not exactly. The { , } construct is somewhat different than ( | ) :
> } for example, when one of the partterns fails, the whole expression
> } fails.
>
> That's what `setopt cshnullglob` is for.  I can't imagine why anyone would
> not want that option when the shell is interactive; brace expansion is
> practically useless without it.

It's true. It always annoyed me that a no match would brake the whole thing.
But I just tried setopt cshnullglob to no avail.
It's still complaining about a no match, even if there are other matches:

dado@saci:~/pdi/timesheet 16 -> setopt | grep null
cshnullglob

dado@saci:~/pdi/timesheet 17 -> ll 99090{0,1,2,3}
UX:ls: ERROR: Cannot access 990900: No such file or directory
UX:ls: ERROR: Cannot access 990903: No such file or directory
-rw-------    1 dado     users         19 Sep  1 20:06 990901
-rw-------    1 dado     users         19 Sep  2 19:39 990902

I also would like to have the same behavior on 99090{0..3}
Is that possible?

Any idea?

Thanks.

ZSH_VERSION=3.0.5
SGI O2 - IRIX 6.5

--
____________________________________________________________________________
d a d o    f e i g e n b l a t t                       direct (650) 846-8386
dado@pdi.com - Technical Lighter                   front desk (650) 846-8100
PDI - Palo Alto, CA                                       fax (650) 846-8101

Re: strange glob expansion

[Bart Schaefer]

On Sep 2,  7:48pm, dado wrote:
} Subject: Re: strange glob expansion
}
} > That's what `setopt cshnullglob` is for.  I can't imagine why anyone would
} > not want that option when the shell is interactive; brace expansion is
} > practically useless without it.
} 
} It's true. It always annoyed me that a no match would brake the whole thing.
} But I just tried setopt cshnullglob to no avail.
} It's still complaining about a no match, even if there are other matches:
} 
} dado@saci:~/pdi/timesheet 16 -> setopt | grep null
} cshnullglob
} 
} dado@saci:~/pdi/timesheet 17 -> ll 99090{0,1,2,3}
} UX:ls: ERROR: Cannot access 990900: No such file or directory
} UX:ls: ERROR: Cannot access 990903: No such file or directory

No, look:  It's not zsh claiming "no match", it's "ls" saying there is no
such file.  Besides, there are no glob patterns in that example, so you
would not get "no match" even if you unsetopt cshnullglob.

This is a subtle but important point:  Brace expansion is not globbing.
Brace expansion happens before globbing; "ll 99090{0,1,2,3}" is exactly
the same as typing out "ll 990900 990901 990902 990903".

In other words, the result of brace expansion is not tested against the
filesystem _unless_ there is also a * ? [] or parenthesized pattern in
that result.  (Or a number range, see below.)

However, if instead you used 99090{0,1,2,3}*, that would expand to
990900* 990901* 990902* 990903*, which zsh would test against the file
names and therefore throw out 990900* 990903* as not matching.  If you
did not use nullglob or cshnullglob, zsh would complain "no match."

} I also would like to have the same behavior on 99090{0..3}
} Is that possible?

In this case, you probably want number ranges:

	ll 99090<0-3>
Or
	ll <990900-990903>

The form lessthan digits hyphen digits greaterthan is a glob pattern, too
(I should have mentioned that in my last message to Adam).  <123-> means
"all numbers greater than 123," <-789> means "all numbers less than 789,"
and <-> means "any number."  This is a bit surprising as it looks like a
redirection, but eventually one runs out of nonalphanumeric characters to
use as delimiters.  Parens were already far too overloaded.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: strange glob expansion

[Hubert Canon]

Bart Schaefer écrivait :
> On Sep 2, 12:15pm, Hubert Canon wrote:
> } Not exactly. The { , } construct is somewhat different than ( | ) :
> } for example, when one of the partterns fails, the whole expression
> } fails.
> 
> That's what `setopt cshnullglob` is for.  I can't imagine why anyone would
> not want that option when the shell is interactive; brace expansion is
> practically useless without it.

I use brace expansion with for constructs most or the time :

for i in {foo,bar,hux}; do touch $i; done

And I don't like setopt cshnullglob because it gives strange behaviour
when I use a single globbing pattern which fails. Like :

grep foo*bar | less

If foo*bar matches nothing, it's exactly like : grep | less
which stops, waiting for input.

It a matter of taste, and that's why options a for.

-- 
Hubert Canon

Re: strange glob expansion

[Bart Schaefer]

On Sep 3,  2:11pm, Hubert Canon wrote:
} Subject: Re: strange glob expansion
}
} I don't like setopt cshnullglob because it gives strange behaviour
} when I use a single globbing pattern which fails. Like :
} 
} grep foo*bar | less
} 
} If foo*bar matches nothing, it's exactly like : grep | less
} which stops, waiting for input.

No, that's not true.  There are two options: NULL_GLOB behaves as you just
described.  CSH_NULL_GLOB will return "no match" in that instance and not
start the grep; it removes patterns silently only when there is more than
one pattern and at least one pattern matches a file.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: strange glob expansion

[Hubert Canon]

Bart Schaefer écrivait :
> No, that's not true.  There are two options: NULL_GLOB behaves as you just
> described.  CSH_NULL_GLOB will return "no match" in that instance and not
> start the grep; it removes patterns silently only when there is more than
> one pattern and at least one pattern matches a file.

Hum. You are right. I didn't know this difference. Thank you.

-- 
Hubert Canon

Re: strange glob expansion

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> On Sep 1, 10:11am, Hubert Canon wrote:
> } Subject: strange glob expansion
> }
> } I tried something like this :
> } 
> } % echo .scwm/(chan*|**/scwmrc*)
> 
> Directory separators can't be used inside parentheses.  Parenthesized
> patterns match within one level of file hierarchy only.  (The '/' may
> still be useful when matching against strings, as in a `case' label, but
> doesn't work when globbing.)

On a related topic, the following puzzles me:

% cd /usr/lib/perl5/site_perl/5.005
% echo L*
LWP LWP.pm Lingua                 (letting you know what's there)
% echo L(*/)
zsh: no matches found: L(*/)      (why doesn't this match the 2 dirs?)
% echo L(*/)#
LWP LWP.pm Lingua                 (why does this match a file?)
% echo L(*/)z
LWP LWP.pm Lingua                 (HUH?)

The upshot of this is that to match all Perl modules starting with `L'
below the cwd, I have to use L{*/**/*,}.pm instead of L**/*.pm.

This is with zsh 3.1.6, no patches.

% uname -a
Linux pulse.localdomain 2.2.10-ac2 #1 Tue Jun 22 10:36:51 BST 1999 i686 unknown

P.S. Is there any movement on making an anonymous CVS tree available?
I'll have a few bug-fixing patchlets ready to submit to zsh-workers
soon, but the rate of development on the list is so ferociously high
that I can't keep up with all the patches.  There have probably been
20 or so already since pws-2!

P.P.S. What version would you rather have patches against?  3.1.6
clean?  The latest pws?

-- 
--- adam@spiers.net --- musician and hacker --- http://www.new.ox.ac.uk/~adam/
echo '$_=bless[q]]],q;_;;sub s;{local$_=shift;push@$_,++$0,pop(@$_).$s;;$_}($,
=eval((join"\$_->[",qw)Just Another Perl Hacker)).q)$_->[1]]]])))=~s~((?<=.(?{
++$*})))?_::~$*&&$"~egx,print""=>""=>'|perl -ln0e';s;s\;;_::AUTOLOAD$1;g;eval'

Re: strange glob expansion

[Bart Schaefer]

On Sep 3,  2:40am, Adam Spiers wrote:
} Subject: Re: strange glob expansion
}
} Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
} > Directory separators can't be used inside parentheses.  Parenthesized
} > patterns match within one level of file hierarchy only.
} 
} On a related topic, the following puzzles me:
} 
} % echo L(*/)
} zsh: no matches found: L(*/)      (why doesn't this match the 2 dirs?)

You've just encountered one of the minor oddities of zsh "glob qualifiers".
At the end of a glob pattern, anything in parentheses is taken to be a glob
qualifier; the qualifier (*/) would mean "match a file that is both a plain
executable file and a directory" which is obviously impossible.

However, "L" is not a glob pattern!  A glob pattern must contain one of *,
?, [], or a parenthesized pattern.  So in that example, (*/) is not a glob
qualifier at all, it is instead a parenthesized pattern that matches any
series of characters followed by a '/' character.  Directory separators
can't be used inside parentheses (he says again), so that pattern can't
match any files no matter how you look at it.

(This actually seems to be different in 3.1.6 -- that is, the trailing
parens are taken as a qualifier even if there are no "magic" characters
to the left of them.  I don't recall if this is intentional or not.)

} % echo L(*/)#
} LWP LWP.pm Lingua                 (why does this match a file?)

This is probably a bug.  That pattern should mean "L followed by any number
of repetitions of any string of characters followed by a slash" (when you
have extendedglob set), which obviously shouldn't match anything either.

Peter's latest patches to 3.1.6 (zsh-workers 7611 and 7624) cause zsh to
complain:

zagzig<8> echo L(*/)#
zsh: bad pattern: L(*/)#

Zsh is being very clever here, as it's only a bad pattern in file-globbing
context, not in string matching context:

zagzig<9> [[ Lazy//lob/ == L(*/)# ]] && echo ok
ok

} % echo L(*/)z
} LWP LWP.pm Lingua                 (HUH?)

That is probably the same bug as L(*/)#.  Zsh is discarding everything
from the '/' onward, because it gets confused by the directory separator
inside the parens, and then matches against L(*).

} The upshot of this is that to match all Perl modules starting with `L'
} below the cwd, I have to use L{*/**/*,}.pm instead of L**/*.pm.

What?  L{*/**/*,}.pm is first brace-expanded to L*/**/*.pm and L.pm, and
then globbed.  There probably isn't an L.pm, so that matches in any sub-
directory whose name starts with L and all its subdirectories, all the
files whose names end with .pm.  You could have done that without the
braces, with L*/**/*.pm, but I suspect what you meant was */**/L*.pm.

You never want ** anywhere except at the beginning of a pattern or in
between a pair of slashes.  Anywhere else it means exactly the same thing
as a single *.

} P.P.S. What version would you rather have patches against?  3.1.6
} clean?  The latest pws?

The latest thing you can manage to patch against.  The more patches from
other people you can keep up with, the better.  If you can't get them all,
identify the base version against which you are patching (where any of
the pws-X releases counts as a "base") and give the article numbers of
any other patches you have applied and upon which yours may depend.  PWS
is pretty good at figuring it out from there.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: strange glob expansion

[Peter Stephenson]

"Bart Schaefer" wrote:
> Peter's latest patches to 3.1.6 (zsh-workers 7611 and 7624) cause zsh to
> complain:
> 
> zagzig<8> echo L(*/)#
> zsh: bad pattern: L(*/)#
> 
> Zsh is being very clever here, as it's only a bad pattern in file-globbing
> context, not in string matching context:
> 
> zagzig<9> [[ Lazy//lob/ == L(*/)# ]] && echo ok
> ok

It occurs to me (finally) that maybe this is the best behaviour, since it
actually lets you know that /'s don't work in parentheses for files.  The
documented behaviour (works up to 3.1.6) is that the / is ignored and
parsing continues after the parentheses, but I guess that was simply to
note what was actually happening rather than an endorsement of it (and the
example with the z shows it was rather flakey).  I have no plans to make
/'s work in groups --- that would require large changes to both the pattern
code and the file scanning code in glob.c --- so if there is no objection
I'll just change the documentation for the new pattern matching code to
recognise the behaviour noted by Bart.

> } The upshot of this is that to match all Perl modules starting with `L'
> } below the cwd, I have to use L{*/**/*,}.pm instead of L**/*.pm.
> 
> What?  L{*/**/*,}.pm is first brace-expanded to L*/**/*.pm and L.pm, and
> then globbed.  There probably isn't an L.pm, so that matches in any sub-
> directory whose name starts with L and all its subdirectories, all the
> files whose names end with .pm.  You could have done that without the
> braces, with L*/**/*.pm, but I suspect what you meant was */**/L*.pm.

I think the answer is **/L*.pm --- as remarked by someone a day or two ago,
**/ can match (very usefully, but slightly counterintuitively given the /)
in the current directory too.  For example, in /usr/local/lib/perl5
`ls **/A*.pm' gives me:
  AnyDBM_File.pm   AutoLoader.pm    AutoSplit.pm     Text/Abbrev.pm

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: strange glob expansion

[Adam Spiers]

Peter Stephenson (pws@ifh.de) wrote:
> "Bart Schaefer" wrote:
> > Adam Spiers <adam@spiers.net> wrote:
> > } The upshot of this is that to match all Perl modules starting with `L'
> > } below the cwd, I have to use L{*/**/*,}.pm instead of L**/*.pm.
> > 
> > What?  L{*/**/*,}.pm is first brace-expanded to L*/**/*.pm and L.pm, and
> > then globbed.  There probably isn't an L.pm, so that matches in any sub-
> > directory whose name starts with L and all its subdirectories, all the
> > files whose names end with .pm.  You could have done that without the
> > braces, with L*/**/*.pm, but I suspect what you meant was */**/L*.pm.
> 
> I think the answer is **/L*.pm --- as remarked by someone a day or two ago,
> **/ can match (very usefully, but slightly counterintuitively given the /)
> in the current directory too.  For example, in /usr/local/lib/perl5
> `ls **/A*.pm' gives me:
>   AnyDBM_File.pm   AutoLoader.pm    AutoSplit.pm     Text/Abbrev.pm

No, I was after all Perl modules starting with `L' in the sense that I
would say that Text::Abbrev started with `T' rather than `A'.  (I
later replace all `/' in the result of the expansion with `::'.)  So I
did mean L**/*.pm, not **/L*.pm.  However, as Bart rightly guessed,
L{*/**/*,}.pm was a load of rubbish.  I actually meant L*{/**/*,}.pm.
Is there a better way of achieving this?