I tried this on a recent version of master and am also having trouble with the $ anchor. I get no results for stone$ or help$. I am able to use ^ successfully.
2.12.3, confirmed that the $ anchor is not working for me in a keyword search but does work in a title search. As noted above is a discrepancy and should be addressed via changing the help text or making it functional as part of a keyword search.
I think the issue here is that this is the nature of the blob. When working on a system with the default keyword indexes, there are so many words that make up the blob, it's hard to know which word will be the last one for that record. As an example, looking at record 2 in the Concerto dataset (Le concerto), the metabib.keyword_field_entry value looks like this:
Le concerto Le concerto Le concerto Ferchault, Guy creator text encyclopedia 127 p. : musique specialized Guy Ferchault. Bibliogr. Concerto ML1263 .F47 Que sais-je? ; 1717 Que sais-je? ; 1717 2130354467 970701 19970807205236.0 2
A search for concerto$ won't work, but 19970807205236.0 2$ successfully retrieves the record. It's not that anchoring is broken; it doesn't work in a way that would be understandable to any end user.
On systems that have added title and other indexes to keyword search for the purposes of weighting, anchoring does work because those indexes will index just the title or just the subject heading. This is why bshum had success with his anchored searches.
Another related bug is bug 1267129, which highlights the problems of using the Matches Exactly search in keyword searches.
We have an upcoming development project that will kill the blob and hopefully resolve these issues.
I can't replicate this failure. When I do a search like stone$ in our system I get records that end in stone.
Marking incomplete pending further review...?