This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Searching Support knowledgebase

While looking for some information on MACs I found article 35338 which contains the string /library/preferences/com.sophos.sau.plist (if it appears split, it isn't). Being the adventurous type I decided to search for sau.plist (without quotes) which to my surprise turned up only 15516 and 16834 but not 35338. And neither did contain sau.plist. Ah - the latter contains Info.plist and the former the word .plist and even though it doesn't say so it also searched for .plist. That's what I thought. But using simply .plist resulted in only one match: 15516. 35338 is only found if I enter the full string - maybe because it's surrounded by a <code> tag. That would explain a few things.

How common is it that an item of interest (e.g. a filename) appears only in a special section (code, blockquote, hn or the like) - in 16384 Info.plist is once inside <h1> and then inside <code>?

Some more tests (using 15516 as "target") made it even more confusing:

Using System Preferences [534] (with or without quotes) returns 15516 only (this suggests that "words" but not "substrings" are matched in special sections) - but  "at path" returns quite a lot. The reason for the latter seems clear: trying to be helpful it's also searching for the individual words and in doing so excludes the common "at" - thus listing all the articles containing path.

Conclusion (wishes):

  1. Special sections should be treated like other text (allowing substring matches)
  2. it should be possible to search for the quoted string only

Christian

:516


This thread was automatically locked due to age.