>> Although the documentation can simply >> be changed to use the new suffix, I argue that the correct fix would >> be to revert the suffix to its original value (without the leading >> dot). > > As the original bug report observed, this does not work with at least > some versions of dircolors, so you couldn't specify a value for LS_COLORS > without the dot. That was the entire point of the bug report.
My concern is that the author of the original bug report might simply have been unaware of the `dircolors` configuration syntax that allows for suffixes without leading dots. This concern is based on the fact that the original bug report never mentions the "*extension" syntax; the bug is purely based on the obsolete ".extension" syntax. Additionally, the bug seems to have been encountered on Arch Linux, whose `dircolors` version definitely supports the "*extension" syntax. Essentially, I'm just worried that this breaking change is based on a simple misunderstanding about the suffixes supported by `dircolors`. >> From here >> (https://lists.gnu.org/archive/html/bug-readline/2023-08/msg00018.html), >> the original motivation for adding the leading dot seems to be that >>> `dircolors` *requires* the file extension to be specified with a leading dot > > The existing code, whatever version it was, certainly did. `dircolors' > rejected the suffix without the leading dot. > It appears that there were versions of dircolors out there that didn't > accept the suffix without a dot. If you are certain that there are versions of `dircolors` that do not accept the suffix without a dot, then my argument is unfounded. I just couldn't find any evidence of such a version, and there didn't seem to be enough justification for a breaking change (to me, at least). On the other hand, I'm not very familiar with the maintenance of GNU software (or free software in general), and I don't really know how much justification is required for such a change.
