On Mon, 4 Aug 2025, Steinar H. Gunderson wrote:
> On Mon, Aug 04, 2025 at 08:54:06PM +1000, Tim Connors wrote:
> > Ok, so it's interpreting [...] as a character class despite me not saying
> > "--regex" nor "--rexexp"?
>
> The man page says:
>
> By default, patterns are taken to be substrings to search for. If at least
> one non-escaped globbing metacharacter (*, ? or []) is given, that pattern
> is instead taken to be a glob pattern (which means it needs to start and
> end in * for a substring match). If --regexp is given, patterns are instead
> taken to be (non-anchored) POSIX basic regular expressions, and if --regex
> is given, patterns are taken to be POSIX extended regular expressions.
> All of this matches mlocate(1) behavior.
I missed that detail when looking at the manpage, but specifically "end
and begin with *". Non intuitive; I had never noticed that behaviour with
mlocate before. I wonder if that could be more prominent in the manpage,
perhaps using a few keywords someone might use to search for such
behaviour, eg:
By default unless there are unescaped glob characters or character
classes (*, ?, []) present in the match, the supplied pattern performs
an exact substring match.
If there are any unescaped globbing or character class metacharacters
present in the match, then the pattern is treated as a glob and must
match the full file basename. To revert to substring match, you would
pre- and append "*" to your match. If --regexp ....
I was also looking for some kind of --literal flag to save from having to
script explicit escapes. There's -N for output but I'd like something
like grep's -F for input.
> > I can't report this issue upstream because the git repo is on ipv6
> > only.
>
> That's fine, I am upstream. You don't need git to report bugs, though.
That was more to see whether the current code had already addressed
anything relevant.
--
Tim Connors