Globbing question

Globbing question

[Dominik Vogt]

Assuming I have a directory with some files and some
subdirectories, e.g.

 subdir/
 anothersubdir/
 ...
 subdir123/
 git/
 file
 anotherfile
 
I'm looking for a globbing pattern that matches all plain files in
all subdirectories except "git".  The pattern

  $ ls -d ^git(/)

gives me all directories except "git", but the next one produces
an error message:

  $ ls -d ^git(/)/**/*(.)
  zsh: bad pattern: ^git(/)/**/*(.)

So my questions are:

1. Why does this pattern not work; what am I missing?
2. What is the correct pattern for the task at hand?

(Note: The reason why I need to exclude "git" from the pattern is
that there are too many files in that directory, so I get an
"zsh: argument list too long" error.)

Ciao

Dominik ^_^  ^_^

Re: Globbing question

[Peter Stephenson]

On Mon, 18 Nov 2013 11:45:43 +0100
Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> I'm looking for a globbing pattern that matches all plain files in
> all subdirectories except "git".

(^git)/**/*(.)

If you want to avoid matching git recursively in subdirectories, too,
you need EXTENDED_GLOB and

(^git/)##**/*(.)

and you'd remove the second "#" to include files in the current
directory.

pws

Re: Globbing question

[Dominik Vogt]

On Mon, Nov 18, 2013 at 11:00:14AM +0000, Peter Stephenson wrote:
> On Mon, 18 Nov 2013 11:45:43 +0100
> Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> > I'm looking for a globbing pattern that matches all plain files in
> > all subdirectories except "git".
> 
> (^git)/**/*(.)

Thanks.

> If you want to avoid matching git recursively in subdirectories, too,
> you need EXTENDED_GLOB and
> 
> (^git/)##**/*(.)

I guess you meant

  (^git)##**/*(.)

(without the slash in the parentheses) because otherwise it does
not work.

> and you'd remove the second "#" to include files in the current
> directory.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: Globbing question

[Peter Stephenson]

On Mon, 18 Nov 2013 12:31:34 +0100
Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> > If you want to avoid matching git recursively in subdirectories, too,
> > you need EXTENDED_GLOB and
> > 
> > (^git/)##**/*(.)
> 
> I guess you meant
> 
>   (^git)##**/*(.)
> 
> (without the slash in the parentheses) because otherwise it does
> not work.

Sorry, what I got wrong is you don't the ** at all because the first
part is doing the recursive search.

(^git/)##*(.)

pws

Re: Globbing question

[zzapper]

> If you want to avoid matching git recursively in subdirectories, too,
> you need EXTENDED_GLOB and
> 
> (^git/)##**/*(.)
> 
How would you specify a second directory to ignore?

zzapper


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: Globbing question

[Eike von Seggern]

On Tue, Nov 19, 2013 at 00:10 +0000, zzapper wrote:
> 
>> If you want to avoid matching git recursively in subdirectories, too,
>> you need EXTENDED_GLOB and
>> 
>> (^git/)##**/*(.)
>> 
> How would you specify a second directory to ignore?

This should work (using Peter's ecent proposal).

(^(git|OTHER)/)##*(.)

Best
Eike

Globbing question

[lists]

Hi all,
	I'm trying to match files which aren't executable for the following 
completion:

zstyle ':completion:*:complete:-command-::commands' ignored-patterns

I tried this:

zstyle ':completion:*:complete:-command-::commands' ignored-patterns 
'*^((x)|(X)|(E))'

thinking that that would translate to "complete everything besides a 
file with the user, group, or other executable bit set", but that 
stopped completing all files which were executable.  Can anyone 
explain?  What is a better way to do this?

Thanks. 
  

Re: Globbing question

[Peter Stephenson]

lists wrote:
> Hi all,
> 	I'm trying to match files which aren't executable for the following 
> completion:
> 
> zstyle ':completion:*:complete:-command-::commands' ignored-patterns
> 
> I tried this:
> 
> zstyle ':completion:*:complete:-command-::commands' ignored-patterns 
> '*^((x)|(X)|(E))'
> 
> thinking that that would translate to "complete everything besides a 
> file with the user, group, or other executable bit set", but that 
> stopped completing all files which were executable.  Can anyone 
> explain?  What is a better way to do this?

The answer to both this and the next question is that unfortunately you
can't use glob qualifiers in ignored patterns.  They are handled as
generic patterns, not specifically file patterns.  This is rather a
nuisance.

It looks like it's probably quite hard to fix.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Globbing question

[Oliver Kiddle]

Peter wrote:
> 
> The answer to both this and the next question is that unfortunately you
> can't use glob qualifiers in ignored patterns.  They are handled as
> generic patterns, not specifically file patterns.  This is rather a
> nuisance.

I wouldn't say it is a nuisance. You can use the file-patterns style
instead to add glob qualifiers where _files is used for completing
files.

_path_files is used for completing files in this case, however. What we
need to ask is why someone should want to complete non-executable files
in command position. (I assume it may be related to suffix aliases). The
necessary change may then be simple. Or at least it would be if the
whole _autocd, _cd stuff wasn't very complicated.

Oliver

Re: Globbing question

[lists]

On Sep 16, 2004, at 10:20 AM, Oliver Kiddle wrote:

> I wouldn't say it is a nuisance. You can use the file-patterns style
> instead to add glob qualifiers where _files is used for completing
> files.
>
> _path_files is used for completing files in this case, however. What we
> need to ask is why someone should want to complete non-executable files
> in command position. (I assume it may be related to suffix aliases). 
> The
> necessary change may then be simple. Or at least it would be if the
> whole _autocd, _cd stuff wasn't very complicated.
>
> Oliver

Maybe I misunderstood the "What we need to ask is why someone should 
want to complete non-executable files in command position" statement, 
but what I'm trying to do is have non-executable files which happen to 
be in my $path *not* be completed.

Thanks.

Re: Globbing question

[Oliver Kiddle]

lists wrote:
> 
> Maybe I misunderstood the "What we need to ask is why someone should 
> want to complete non-executable files in command position" statement, 
> but what I'm trying to do is have non-executable files which happen to 
> be in my $path *not* be completed.

I hadn't realised that they are completed by default but a quick check
reveals that they are.

command names are not completed by using the usual filename completion.
Instead the shell's internal hash table of commands is used. If you run
the hash builtin, it lists non-executable files. Quite why it does this,
I don't know but presumably it is an optimisation of some sort.

So it looks like there isn't an easy way to fix the completion.

Oliver

Re: Globbing question

[Peter Stephenson]

Oliver Kiddle wrote:
> Peter wrote:
> > The answer to both this and the next question is that unfortunately you
> > can't use glob qualifiers in ignored patterns.  They are handled as
> > generic patterns, not specifically file patterns.  This is rather a
> > nuisance.
> 
> I wouldn't say it is a nuisance. You can use the file-patterns style
> instead to add glob qualifiers where _files is used for completing
> files.

OK, so you're saying that in most contexts, you can do something like

  zstyle ':completion:*' file-patterns '*(#q-*)'

to complete only executable files, but the specific example

  zstyle ':completion:*:complete:-command-::commands' file-patterns '*(#q-*)'

doesn't work because it goes through the code the wrong way?  I would
say that *is* an annoyance, and that 99% of users don't care about
the difference between _files and _path_files.

Some cross-referencing between ignored-patterns and file-patterns might
be beneficial, too.

Presumably a side effect of using file-patterns is the _ignored
completer doesn't pick up the remaining files, but if I remember there
are ways of doing this with the all-files tag.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Globbing question

[Oliver Kiddle]

Peter wrote:

> OK, so you're saying that in most contexts, you can do something like
> 
>   zstyle ':completion:*' file-patterns '*(#q-*)'
> 
> to complete only executable files, but the specific example

That's right. (The #q isn't needed though.)

>   zstyle ':completion:*:complete:-command-::commands' file-patterns '*(#q-*)'
> 
> doesn't work because it goes through the code the wrong way?  I would

Turns out that executables are added by using `compadd -k commands' so
it isn't filename based completion at all.

> say that *is* an annoyance, and that 99% of users don't care about
> the difference between _files and _path_files.

The only difference between _path_files and _files is that _files looks
up file-patterns. _path_files should only be used if there is a good
reason to disallow file-patterns.

Styles are there for adjusting things according to user preferences not
for fixing bugs in the underlying code. So the "annoyance" is not that
file-patterns or ignored-patterns can't handle this.

> Some cross-referencing between ignored-patterns and file-patterns might
> be beneficial, too.

Yes that's true.

> Presumably a side effect of using file-patterns is the _ignored
> completer doesn't pick up the remaining files, but if I remember there
> are ways of doing this with the all-files tag.

You can call the tag what you like. The value of file-patterns is a list
much like tag-order. It just happens that the default value includes an
all-files tag with the pattern *.

Oliver