view release on metacpan or  search on metacpan

bin/gre  view on Meta::CPAN

    $ gre -noperl

will show all files except perl files.

There are two levels of filtering that run independent of each
other. One level is the "include" filters like -perl, -nophp, or
-ext=c.  The second level is the "exclude" filters like -xname=foo
or -xbinary.

Why are they independent?  Consider if the script had a default
filter to remove all backup files (-xname='~$') which would have
to mix with additional command line filters.  The following would
try to search for bash files (files whose first line starts with
#!/bin/bash) that aren't backups:

    $ gre -xname='~$' -line1='^#!/bin/bash'

It wouldn't work if they weren't independent: filters are additive,
so this would have added all files which are not backups then add
all files which are bash files (some of which may be backup files).

The reason the filters have to be additive is to let commands like
this work:

    $ gre -html -js

which will find all html and javascript files.

If I added the builtin filters after the command line arguments:

    $ gre -line1='^#!/bin/bash' -xname='~$'

Then you wouldn't have a chance to disable it:

    $ gre -line1='^#!/bin/bash' -noxname='~$' -xname='~$'

It would still filter out the backup files.

The result should be intuitive. For example, if you want to
search everything except one file that's messing up the search add:

    $ gre -xname=INBOX.mbox -ext=mbox qwerty

and you wouldn't have to worry about order of these filters.

If you want to remove all the builtin "exclude" filters, use -x on
the command line. By default, gre will exclude backup files, swap
files, core dumps, .git directories, .svn directories, binary files,
minimized js files, and more. See the output of -c for the full
list.

"exclude" filters also have another property which the regular
"include" filters don't have: They prune the recursive file search.
So -xnamee=.git will prevent any file under a .git directory from
being searched (the extra e at the end of -xname means to use
string equality not regexp's for the match). Normal "include"
filters do not execute on directories.

lib/App/Gre.pm  view on Meta::CPAN

    $ gre -noperl

will show all files except perl files.

There are two levels of filtering that run independent of each
other. One level is the "include" filters like -perl, -nophp, or
-ext=c.  The second level is the "exclude" filters like -xname=foo
or -xbinary.

Why are they independent?  Consider if the script had a default
filter to remove all backup files (-xname='~$') which would have
to mix with additional command line filters.  The following would
try to search for bash files (files whose first line starts with
#!/bin/bash) that aren't backups:

    $ gre -xname='~$' -line1='^#!/bin/bash'

It wouldn't work if they weren't independent: filters are additive,
so this would have added all files which are not backups then add
all files which are bash files (some of which may be backup files).

The reason the filters have to be additive is to let commands like
this work:

    $ gre -html -js

which will find all html and javascript files.

If I added the builtin filters after the command line arguments:

    $ gre -line1='^#!/bin/bash' -xname='~$'

Then you wouldn't have a chance to disable it:

    $ gre -line1='^#!/bin/bash' -noxname='~$' -xname='~$'

It would still filter out the backup files.

The result should be intuitive. For example, if you want to
search everything except one file that's messing up the search add:

    $ gre -xname=INBOX.mbox -ext=mbox qwerty

and you wouldn't have to worry about order of these filters.

If you want to remove all the builtin "exclude" filters, use -x on
the command line. By default, gre will exclude backup files, swap
files, core dumps, .git directories, .svn directories, binary files,
minimized js files, and more. See the output of -c for the full
list.

"exclude" filters also have another property which the regular
"include" filters don't have: They prune the recursive file search.
So -xnamee=.git will prevent any file under a .git directory from
being searched (the extra e at the end of -xname means to use
string equality not regexp's for the match). Normal "include"
filters do not execute on directories.