sfind should print a diagnostic message on encountering a loop #27

Closed
opened 5 months ago by tavianator · 5 comments

The POSIX spec for find says:

The find utility shall detect infinite loops; that is, entering a previously visited directory that is an ancestor of the last file encountered. When it detects an infinite loop, find shall write a diagnostic message to standard error and shall either recover its position in the hierarchy or terminate.

But sfind doesn't:

tavianator@tachyon $ mkdir loop
tavianator@tachyon $ ln -s . loop/loop
tavianator@tachyon $ ./sfind/OBJ/x86_64-linux-gcc/sfind -L loop
loop
loop/loop
tavianator@tachyon $

In addition to the diagnostic message, sfind should exit with a non-zero exit code, because:

STDERR

... Otherwise, the standard error shall be used only for diagnostic messages.

and the Utility Description Defaults say

STDERR

Default Behavior: When this section is listed as "The standard error shall be used only for diagnostic messages.", it means that, unless otherwise stated, the diagnostic messages shall be sent to the standard error only when the exit status indicates that an error occurred and the utility is used as described by this volume of POSIX.1-2017.

The [POSIX spec for find](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html) says: > The *find* utility shall detect infinite loops; that is, entering a previously visited directory that is an ancestor of the last file encountered. When it detects an infinite loop, *find* shall write a diagnostic message to standard error and shall either recover its position in the hierarchy or terminate. But sfind doesn't: ``` tavianator@tachyon $ mkdir loop tavianator@tachyon $ ln -s . loop/loop tavianator@tachyon $ ./sfind/OBJ/x86_64-linux-gcc/sfind -L loop loop loop/loop tavianator@tachyon $ ``` In addition to the diagnostic message, sfind should exit with a non-zero exit code, because: > ### STDERR > > ... Otherwise, the standard error shall be used only for diagnostic messages. and the [Utility Description Defaults](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04) say > ### STDERR > > **Default Behavior:** When this section is listed as "The standard error shall be used only for diagnostic messages.", it means that, unless otherwise stated, the diagnostic messages shall be sent to the standard error only when the exit status indicates that an error occurred and the utility is used as described by this volume of POSIX.1-2017.
herrhotzenplotz was assigned by clausecker 5 months ago
Owner

I am not sure if returning a non-zero exit status for directory loops is the desired behaviour. Such loops crop up every once in a while and are harmless if caused by symbolic links. If find(1) failed because of such a loop, it would make it much more annoying to use.

Other implementations behave as follows:

  • FreeBSD find(1) silently breaks directory loops, does not give a diagnostic message and does not return a positive exit status
  • GNU find(1) behaves as you propose
  • so does SunOS find(1)

I may file an interpretation request about this issue.

I am not sure if returning a non-zero exit status for directory loops is the desired behaviour. Such loops crop up every once in a while and are harmless if caused by symbolic links. If find(1) failed because of such a loop, it would make it much more annoying to use. Other implementations behave as follows: * FreeBSD find(1) silently breaks directory loops, does not give a diagnostic message and does not return a positive exit status * GNU find(1) behaves as you propose * so does SunOS find(1) I may file an interpretation request about this issue.
Owner

@tavianator Could you check if PR !30 fixes the issue as you envisioned?

Will put together an interpretation request in the next days.

@tavianator Could you check if PR !30 fixes the issue as you envisioned? Will put together an interpretation request in the next days.
Poster

@clausecker Just tried it, it does fix the test case.

@clausecker Just tried it, it does fix the test case.
Owner
Please see [PASC interpretation request 1606](https://austingroupbugs.net/view.php?id=1606).
Owner

Your interpretation has been confirmed by Geoff Clare of Austin Group. I'll go ahead and commit PR !30.

Your interpretation has been confirmed by Geoff Clare of Austin Group. I'll go ahead and commit PR !30.
clausecker closed this issue 5 months ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: schilytools/schilytools#27
Loading…
There is no content yet.