doc: autogenerated links with 404 status

[vsemozhetbyt]

There are some links in the docs that get 404 recently:

http://man7.org/linux/man-pages/man1/curl.1.html in repl.html (1 link).
http://man7.org/linux/man-pages/man3/uname.3.html in os.html (3 links).

They are wrongly rendered:

They have been fixed with manually added URLs in #10244 and #15463, but have been reverted to autogenerated URLs (with autogenerated URLs being prioritized/rewritten above manual URLs) in the #17479

cc @DiegoRBaquero and @apapirovski as maybe more well-informed about the tools/doc/html.js script.

[DiegoRBaquero]

Manually linked links shouldn't be matched.

But also:

uname should be pointed to http://man7.org/linux/man-pages/man1/uname.1.html, shouldn't it?

And curl's manpage is fixed to one section, always updated. Maybe remove the section?

[vsemozhetbyt]

It seems they are matched because of bottom reference format: [curl(1)][] is matched now after space is replaced by \b.

I am not well aware of UNIX manpages system, those manual URLs were advised by other collaborators, so I only have alerted the issue here, sorry) Feel free to fix in any appropriate way)

[vsemozhetbyt]

Maybe we should just change \b to [^\B[] to exclude this link format from redundant autoconversion? I am not sure there will be no new side effects though.

[vsemozhetbyt]

See also #17694

[Trott]

Maybe replace word boundary \b with an allowance for spaces or the beginning of a line (^|\s). That will stop it from replacing if the word break is a non-alpha symbol like [ and ( but still work at the start of a line.

[maclover7]

Hmmmm, so I didn't think #17724 would fix this (was focusing on the child process doc issue when landing), but looks like it did locally on my machine. Are other people seeing this too? You can verify by checking for curl(1) in repl, and uname(3) in os. Going to let the nightly run and check back tomorrow.

[vsemozhetbyt]

As per the last nightly, this seems to be fixed as well. Thanks!)