bug#64791: 30.0.50; [PATCH] Fix dired mismatch on some filenames

[Manuel Giraud]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>>> Cc: 64791@debbugs.gnu.org
>>> Date: Sat, 22 Jul 2023 16:46:27 +0200
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > I'm not sure there can be the end to such fixes.  The real fix is to
>>> > use GNU 'ls' which has special support for Dired (or use ls-lisp.el).
>>> > I guess you don't have GNU 'ls', since you are on OpenBSD?
>
> Yup.  Perhaps we should consider checking for the existence of "gls" and
> using that.  E.g., I use the following, here:
>
>   (if (and (memq system-type '(berkeley-unix darwin))
>            (executable-find "gls"))
>       (setq insert-directory-program "gls"))
>
> But I've only tested this on macOS so far, so I'm not sure how well this
> would work on *BSD.  From memory, I think it should be fine.  Perhaps
> Manuel can say what he thinks.

It would work also on OpenBSD because GNU ls is also called "gls" in the
coreutils package here.  BTW, Could you reproduce this bug with default
ls on macOS?

>>> You're right I'm using OpenBSD's ls.  But I thought it was a reasonable
>>> fix: it seems more obvious then looking for something that looked like a
>>> file size.
>>
>> Maybe.  Let's hear what others think about this.
>
> FWIW, I don't think I mind such portability fixes.  It wouldn't be a bad
> thing if Dired played a bit more nicely on BSD machines.

Yes and I still think that this patch is reasonable even though someone
is using GNU ls.  It went "look for something that looks like a file
size" to "go directly after column 5 where the modification is
starting".  I find the former more error prone than the latter.

But maybe, I'm missing something about all the architectures (Unix and
non-Unix) that Emacs supports.
-- 
Manuel Giraud