Hans-Bernhard Bröker wrote: > Am 05.07.2026 um 05:18 schrieb Keith Thompson via Cygwin: > >>> Firstly, why is =~ completely undocumented in the bash man page? This > >>> question was my first encounter with the feature. > >> · > >> Because it's not --- not undocumented, that is. Manpage search can't > >> seem to find it, but it _is_ there. > >> · > >> Just search for '==' instead, then go one paragraph down. > > Searches in man pages are controlled by your pager ($PAGER or > > $MANPAGER). Your pager might be treating the ~ character specially. > > Try searching for \~= . >· > It doesn't appear to be the pager --- it's groff translating the ~ to· > some other character. One which I don't know how to type into the· > search pattern. >· > What does help for me is overriding the language spec: >· > $ LC_ALL=C man bash >· > and, voila, / finds =~ just fine. >· > And FWIW, 'info bash' doesn't have that problem, either.
You're right, I should have realized that. groff 1.23.0 changed the way '-', '~', and '^' characters are rendered. This affects a *lot* of man pages. ASCII '-' (U+002D, HYPHEN-MINUS) is translated to '‐' (U+2010, HYPHEN). ASCII '~' (U+007E, TILDE) is translated to '˜' (U+02DC, SMALL TILDE). ASCII '^' (U+005E, CIRCUMFLEX ACCENT) is translated to '‐' (U+02C6, MODIFIER LETTER CIRCUMFLEX ACCENT). Hyphens have been the biggest problem. Searching a man page for an option name often fails because of this. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
