bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39929: coreutils-8.32 fails to build on aarch64


From: Bernhard Voelker
Subject: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Fri, 6 Mar 2020 08:36:07 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 2020-03-06 08:31, Bernhard Voelker wrote:
> On 2020-03-06 02:27, Paul Eggert wrote:
>> On 3/5/20 1:43 PM, Paul Eggert wrote:
>>
>>> Why is this code even there at all? If readdir(3) says that the current
>>> directory has no entries, shouldn't 'ls' just say that? Why should ls
>>> report an error simply because the current directory isn't reachable
>>> from the filesystem? Whether the current directory is unreachable has
>>> nothing to do with ls's job, which is to report whether the current
>>> directory has entries.
>>
>> Attached is a proposed patch to fix this.
> 
> I tend to agree (now): returning an error when there was none seems at least
> unlucky.  Sorry I didn't comment in the original discussion.
> 
>> diff --git a/tests/ls/removed-directory.sh b/tests/ls/removed-directory.sh
> 
> That test was also added in commit 05a99f7d7f8e, so the the description
> at the top does not match after reverting:
> 
>   #!/bin/sh
>   # If ls is asked to list a removed directory (e.g. the parent process's
>   # current working directory that has been removed by another process), it
>   # emits an error message.
> 
> s/emits/shall not emit/

P.S. Also the check for $host_triplet containing 'linux' in test is:
a) no longer needed, and
b) looks like a good argument to revert 05a99f7d7f8e, because it introduced
different (and user-visible) behavior just because of the platform.

Have a nice day,
Berny





reply via email to

[Prev in Thread] Current Thread [Next in Thread]