Hello, James Cloos wrote on Wed, Aug 27, 2025 at 12:20:26PM -0400: > >>>>> "IS" == Ingo Schwarze <schwa...@usta.de> writes:
> JC>> I hope none of you are suggesting removing support for, eg: > JC>> man ./foo.5 > IS> We will remove exactly that. Done: https://cvsweb.openbsd.org/src/usr.bin/mandoc/main.c#r1.266 I am not going to provide an option for downstreams to re-enable the quirk, not even for any Linux distributions, because maintaining such an option would entail even more maintenance and testing effort than having the feature enabled for everyone. In general, options are *way* worse maintenance-wise than things that are always active. [...] > and there is never value in eliminating something which has been > around for decades and is effortless to maintain. Nothing is ever effortless to maintain, neither in general nor in this particular case. For example, implementing this feature required tricky open(2) O_DIRECTORY and fchdir(2) gymnastics that made the code more fragile and could now be removed, making the code simpler and hence easier to understand, audit, debug, and maintain, hence helping overall code quality. Also, the value of removing poorly thought-out features lies not only in making the code simpler and hence better, but also in making the user interface simpler and hence better. This particular feature was not only hard to document properly (at least not without making the manual significantly harder to read and understand, in particular for new users), but also caused ambiguous behaviour. While the now removed mandoc(1) behaviour was designed to replicate the man-db behaviour as closely as possible, if the old man-1.5 and man-1.6 manuals are accurate, the behaviour of that program was *not* consistent with man-db: man-db only uses the quirk as a fallback when a name is not found, whereas the man-1.6 documentation says it always used the quirk for all names containing slashes - which would make it impossible to have manual pages with names containing slashes. > i can't be the only one who is used to the current support. > on any kernel or dist. No, in fact, i know of one other person who also used the quirk, who also thought there was no other way to achieve the effect, and who spoke up about seven years ago. But having a small number of users who have gotten used to an ill-designed feature is not a good reason to make everyone suffer from the presence of that feature in all eternity, in particular not when a better designed, less ambiguous variant of the same feature (-l) has been around for a comparable time. It looks like https://xkcd.com/1172/ is on full display here - yesyes i know, what we have here is not quite as outrageous, but the common point is that a feature that harms many (even if only a little) and helps few (if any at all) should be removed. > the discussion ought to be much more widespread before changes > are made. Not really. I think all relevant arguments have been brought up, and it was found that the question boils down to overall UI design quality and code quality vs. finger memory of a (likely limited) number of users. Even a few ideas for deprecation paths to not harm scripts and infrastructure have already been discussed. What kind of qualitatively new arguemnts would you expect? Besides, i can't think of a better forum than the man-db and groff lists: good luck if you want to try to find a forum where you can talk to Federico Lucifredi, Andries Brouwer, Graeme Wilford, or John Eaton... That said, if we encounter fallout down the road in OpenBSD, which i doubt at this point, or later on in other systems using mandoc as their default man(1) implementation (which were mostly Alpine Linux, Void Linux, Termux, and Chimera Linux last time i looked) i *am* planning to notify Colin via the man-db list such that he can use the information for his own upcoming deprecation effort. Yours, Ingo
