Subject: Re: bug#34816: 25.2; dired regexp fails for filenames that begin with a space
From: Michael Albinus <[email-masked]>
To: Stefan Kangas <[email-masked]>
Cc: Andrew Eggenberger <[email-masked]>, [email-masked]
Date: Tue, 18 Aug 2020 19:42:39 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Stefan Kangas <[email-masked]> writes:

Hi,

>>> Trying to use dired-do-rename-regexp caused the following error:
>>>
>>> (file-error Renaming No such file or directory
>>> /Users/andrew/Public/Temp_2019/Temp_2.25.19/Tiger Pride/- 1B, Thieren,
>>> Addison.JPG /Users/andrew/Public/Temp_2019/Temp_2.25.19/Tiger
>>> Pride/Addison, Thieren.jpg)
>>>
>>> The reason for the file error is that the filename actually begins
>>> with
>>> a space character before the hyphen. It appears that the mechanism
>>> used to identify filenames within dired isn't sensitive to opening
>>> spaces.
>>
>> It isn't as simple as it looks. Often, dired uses a command like "ls -al
>> --dired". This gives precise information, where file names are located
>> in the output, and Emacs could determine also file names starting with
>> spaces.
>>
>> If this ls option isn't available, something like "ls -al" is
>> applied. From the output it isn't obvious, whether a leading space
>> belongs to a file name, or whether it is just a separator to the
>> date. One could implement heuristics (check the column other file names
>> start with), but this isn't implemented.
>>
>> If it comes to remote file names, the situation is even worse, because
>> you cannot always assume a proper ls command on the remote side.
>>
>> One alternative for you might to use ls-lisp.el. It doesn't apply "ls
>> -al", but tries to collect the needed information differently. Due to
>> this, dired might have a better idea about file names.
>
> So is the conclusion here to either use GNU ls, or otherwise ls-lisp.el?
> If so, should this bug be closed?

I would say so, yes. Closing the bug.

> Best regards,
> Stefan Kangas

Best regards, Michael.