Question: Matches on file paths

[Akash-Mair]

Hi!

Is it possible to also match on file paths? So if I have a key word that is found in an file path it is returned in some kind of output?
If so I must just be missing the flag!

Many thanks :)

[genivia-inc]

There are flags to include or exclude directories that match a glob of the (sub)directories on the paths to search or exclude using option -g (or --glob or --iglob).

For example, ug -g"/*/dir/*/file.txt" pattern searches the working directory down to */dir/*/file.txt. The leading / ensures that the path matches the start of the working directory.

If the include or exclude flags don't suffice, then you can always use find to generate the paths you want to search ugrep with, e.g. find . -path "GLOB" -print or find . -regex "PATTERN" -print. The find-generated paths are passed on to ugrep using xargs. For example find . -path GLOB -print | xargs ugrep PATTERN --. Note that I'm using -- at the end of ugrep to avoid paths that start with - to be interpreted as command-line options. It's typical UNIX way of doing things with xargs that is very powerful and customizable. The xargs utility is there to use it for many such scenarios with tools that take paths, including this one.

[genivia-inc]

It might be a good idea to extend the glob options matching functionality to perform like find -path PATH more closely. The -g"PATH" option does this at the moment, but not efficiently. Also, --include-dir="PATH" (or -g"PATH/" with trailing /) does not work as expected, because right now, the glob options are aligned with GNU/BSD grep, but also support gitignore-style globbing and .gitignore files. So there is a difference in the interpretation of --include-dir="DIR" globs (or the same with -g"DIR/"), which is not a path but a (sub)directory name to match, whereas find -path "PATH" finds files on the specified PATH glob.

[genivia-inc]

I have an update to improve the speed of -g"PATH", which is not great right now, because recursive searches explore too many directories outside of the specified PATH glob. My dev version is ready and tested. However, there are additional decisions to be made.

Using -g"PATH (or --glob="PATH" or --iglob="PATH") does what it is supposed to with globs to match, as is already implemented in ugrep. However, when used in combination with --include-dir="PATH", some interesting and contradictory things may happen.

For example:

• -g"dir/" searches for files in any dir deep from the working directory, ignoring all other (sub)directory names, same as --include-dir="dir"
• -g"dir1/dir2/file" searches for file in dir/dir2 from the working directory
• -g"dir1/dir2/file" -g"dir/" can be specified too, but it is not clear what should happen

For the last example, the files searched could be limited to dir1/dir2/file only, which after all is what is necessary to find. But what about dir? Should we also search there to find all possible files in dir, dir/dir, dir/dir/dir and so on? However, we specified file as a search target, which seems to contradict searching in dir? The question is about mutual exclusion of these cases or if the cases should be correlated. Whatever decision, some may agree or disagree.

[genivia-inc]

After some experimentation, I've decided that basename globs override path globs when both are specified (as a use case that is not common), which means that searching is is determined by the basename directories you want to search in. That is more intuitive, I think. This still means there can be conflicts that produce no results, when basename directories are only searched but a more specific path is given e.g. -g"dir1/dir2/file" -g"dir/" does not return matches, because we only want to search in dir (same as --include-dir="dir") directories as basename. The path dir1/dir2/fileis never part of the recursive search, which is considered a useless constraint when the only directory we visit isdir`. I'm sure some may disagree, but something must be decided to move forward. There can be more interpretations with this conflicting/ambiguous situation. For clarity, avoid conflicts by specifying either paths to targets to search or by specifying the basenames of directories to search.

I'm also going to enable recursive searching implicitly as a new feature when a glob is specified that is a path, so that ugrep recurses to match the path. For example, ug -g"dir1/dir2/file '' dir1 will recurse into dir1 to find dir1/dir2/file there.

[genivia-inc]

Ugrep 7.4 is released with improved -g"path/file" (--glob="path/file" and --iglob="path/file"), --include=GLOB, --include-dir=GLOB options.