GNU bug report logs - #64791
30.0.50; [PATCH] Fix dired mismatch on some filenames

Previous Next

Full log

Message #23 received at 64791 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64791 <at> debbugs.gnu.org
Subject: Re: bug#64791: 30.0.50; [PATCH] Fix dired mismatch on some filenames
Date: Sun, 03 Sep 2023 16:04:01 +0200

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>>> Cc: 64791 <at> debbugs.gnu.org
>>> Date: Sat, 22 Jul 2023 16:46:27 +0200
>>>
>>> Eli Zaretskii <eliz <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.