schilytools
/
schilytools
4
12
Fork 5
Code Issues 17 Pull Requests 1 Projects Releases 5 Wiki Activity
Labels Milestones
New Issue

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

Closed
opened 5 months ago by tavianator · 5 comments
tavianator commented 5 months ago

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
clausecker commented 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.
👍 1
clausecker commented 5 months ago
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.
tavianator commented 5 months ago
Poster

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

@clausecker Just tried it, it does fix the test case.
clausecker commented 5 months ago
Owner

Please see PASC interpretation request 1606.

Please see [PASC interpretation request 1606](https://austingroupbugs.net/view.php?id=1606).
clausecker commented 5 months ago
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 Branch/Tag Specified
Branches Tags
master
test-sh-bug
Labels
Apply labels
Clear labels
Kind: Breaking Kind: Bug Kind: Documentation Kind: Enhancement Kind: Feature Kind: Maintenance Kind: Question Kind: Security Kind: Testing Priority: Critical
The priority is critical Priority: High
The priority is high Priority: Low
The priority is low Priority: Medium
The priority is medium Reviewed: Confirmed
Something has been confirmed Reviewed: Duplicate
Something exists already Reviewed: Invalid
Something was marked as invalid Status: Blocked Status: Completed
Work is complete Status: Help wanted Status: In progress
Work is in progress Status: Needs feedback
Feedback is needed Status: Stale
No Label Kind: Breaking Kind: Bug Kind: Documentation Kind: Enhancement Kind: Feature Kind: Maintenance Kind: Question Kind: Security Kind: Testing Priority: Critical Priority: High Priority: Low Priority: Medium Reviewed: Confirmed Reviewed: Duplicate Reviewed: Invalid Status: Blocked Status: Completed Status: Help wanted Status: In progress Status: Needs feedback Status: Stale
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
herrhotzenplotz
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: schilytools/schilytools#27
Write Preview
Loading…
Cancel
Save
There is no content yet.
Delete Branch '%!s(<nil>)'

Deleting a branch is permanent. It CANNOT be undone. Continue?

No
Yes