carat prefix ignored in search

[DavidHoffmanuk]

Mac OS 10.14.6

I'm using this search term:
filename ^C11 or ^C12 OR ^C13 OR ^D7 OR ^D8 OR ^D9 OR ^D10 or ^D13
and the results include files with the strings within the name, not at the start as I expected. I get names starting C11, C12 etc but also names starting YC11, YC12 as well. See attached screenshot.

I've tried
filename (^C11 or ^C12 OR ^C13 OR ^D7 OR ^D8 OR ^D9 OR ^D10 or ^D13)
which gives the same result. And I've tried
filename ^C11 or filename ^C12 OR filename ^C13 OR filename ^D7 OR filename ^D8 OR filename ^D9 OR filename ^D10 or filename ^D13)
which gives no results - also puzzling.

What am I not understanding?

[Bill Kelly]

Hi David,

I'm using this search term:
filename ^C11 or ^C12 OR ^C13 OR ^D7 OR ^D8 OR ^D9 OR ^D10 or ^D13
and the results include files with the strings within the name, not at the start as I expected. I get names starting C11, C12 etc but also names starting YC11, YC12 as well. See attached screenshot.

Does it make a difference if the terms are quoted? E.g.

  filename ^"C11" or ^"C12" or ^"C13"

[DavidHoffmanuk]

Many thanks Bill - you're spot on!

filename ^"C11" or filename ^"C12" OR filename ^"C13" OR filename ^"D7" OR filename ^"D8" OR filename ^"D9" OR filename ^"D10" or filename ^"D13"

does what I'd expected.

Is there an explanation as to the way to use quotes? I've not found one other than for specific strings so I don't see why they should be needed here when the start of the string is already specified.

The other simpler variants like
filename ^"C11" or ^"C12" OR ^"C13" OR ^"D7" OR ^"D8" OR ^"D9" OR ^"D10" or ^"D13"
also work as expected.

Apologies for the slow reply, I forgot to switch notification on.

[Bill Kelly]

Is there an explanation as to the way to use quotes? I've not found one other than for specific strings so I don't see why they should be needed here when the start of the string is already specified.

I think you're right. Our query parser should probably behave as though quotes had been used, in this scenario.

(The technical explanation for the current behavior is that unquoted terms use sub-string matching: so searching for bud would match rosebud, but searching for "bud" only finds that exact term. So, even though you've specified ^ to anchor to the start of the string, it's still trying to do sub-string matching when terms are unquoted.)

[DavidHoffmanuk]

Hi Bill

I thought that using quotes around the string I want to find at the start of the filename had fixed the problem but there are still anomalies in my search results and I'm still unable to find (for example) only filenames starting n12-. I think that the attached screenshots show this better than trying to write out each query and describing the result but let me know if it’s not clear and I'll expand on this.

David

[Bill Kelly]

Hi David,

I thought that using quotes around the string I want to find at the start of the filename had fixed the problem but there are still anomalies in my search results

Unfortunately, it appears you've hit a case which is outside the original design of our search engine, which operates at the level of keywords or quoted phrases, rather than at the level of positional matching of substrings or spans-of-characters within a word.

I've added an issue to our project tracker to research adding the missing functionality.

I don't have a great workaround in the meantime. Best I can think of is to use an unquoted anchored search, like filename ^n12 and then sort by filename, so that at least the results starting with "n12" will be grouped together.

Sorry for the inconvenience.

-Bill

[DavidHoffmanuk]

Thanks for the explanation. On the plus side, I won't need to spend more time trying to see what I'm doing wrong.

If this is something that PM will work on in the future then perhaps PM might look at adding wildcards too?

David