Some Dashes/Hyphens in rsync's Manual Page on -current Are Different
 

Hello folks,

Today when searching for one of rsync's long options that I know for a fact it has, my pager (less) said it wasn't able to find the pattern I fed it, which was just "--compress-choice".

It was however, able to find "--compress" when I noticed just beneath it, the "--compress-choice" option was there but the hyphen/dash after the last 's' in "compress" wasn't the same as the first two hyphens/dashes in the long option.

I fired up a clean -current VM to see if it happened to be some personal changes I made on my own laptop or if it had been my terminal but it wasn't and the clean -current VM had the same issue.

A quick glance through the "rsync.1" file in the source tarball shows the dashes/hyphens that can get searched are escaped. Here's a small snippet:
With that said:

1. Does anyone else have this issue on -current specifically with rsync's man page?

There may be others but I can only confirm this issue with rsync on my end.

2. What regular expression could properly and inconsequentially substitute all cases of the un-escaped '-' with the escaped variant?

With an iso8859-1 locale, it's the same '-', 2D, so it is easily found by less.

Slackware now has a UTF-8 default locale where it's '‐', HYPHEN, E2 80 90. If you copy this using your mouse: '--compress‐choice', you can find it with less.

Or, you could use a regular expression. Search for '--compress.choice'.

Background reading:
https://lwn.net/Articles/947941/

The hyphen that doesn't match really should be escaped in the man-page in order to make it a '-' ascii 0x2d. It's the same on my CRUX system. Upstream's rsync's man-page is just wrong.


I'm not sure how Slackware builds less, but on CRUX with LESS 643 built using the PCRE2 regex library it seems that the less code doesn't prefix the search term with the needed (*UTF8) prefix to get '.' to match a single multibyte utf8 sequence therefore
/--compress.choice doesn't work, but
/(*UTF8)--compress.choice does. As does:
/--compress...choice (with hyphen being a 3 byte sequence)

I would argue that less should be doing this prefixing internally¹ to enable utf8 matching when run in a utf8 locale and that this is a bug, but that might be a matter of opinion (It's possible less devs chose to do this for performance reasons).

-----
1) reading the man-pages for pcre2, seems there are also corresponding options one can pass to the functions. So I assume less isn't doing that.