Fd: Issue error messages (eg permission denied)

[HaleTom]

If fd can't search a directory, there is no notification:

% mkdir -m000 noperms
% fd -HI moo noperms
%

I'd expect a permission denied by default.

If not default (why not? that's what STDERR is for), perhaps add a switch to enable them.

[sharkdp]

Thank you for the feedback.

I agree. We should definitely make a plan on how to deal with such errors.

I'm not sure if we should always show them by default, but I agree that we should definitely show an error message if one of the explicitly given search directories can not be traversed.

[bernardobelchior]

What if the errors were shown by default, but there was a flag to suppress them?
This way the user could still be alerted when an error occurred. On the other hand, the flag could be used in an automation perspective, like piping output to other tools.

[HaleTom]

STDOUT (File descriptor 1) gets piped to the next command if there is a pipe.

For errors, there's STDERR (FD 2) which gets connected to the terminal by default, but can be redirected to /dev/null (or anywhere else):

command 2> /dev/null

Similar behaviour in Windows

This is standard Unix design philosophy, where MS got it from. Not having errors enabled by default will raise many eyebrows without a solid reason to deviate from established practice.

Not showing errors by default means that possibly matching files which can't be accessed due to permissions issues will never be highlighted.

[psinghal20]

Hi, I am new to Rust and wanted to gain some experience by contributing to the open source community. Is this issue still there? If yes, could you give me some pointers on how to proceed with the issue? Thanks!

[HaleTom]

Thanks for wanting to help out!

I'm not a rust man, but this does look like a good starting project.

The issue persists.

I suggest you tag some of the others above for guidance - I can't do that this Fasthub app.

[psinghal20]

@sharkdp Could you help me in proceeding with this issue? Any tips would be helpful!

[sharkdp]

@psinghal20 Thank you for offering to help out!

A quick disclaimer: I did initially put the "good first issue" label on this ticket, but I now realize that it's probably not the most beginner-friendly thing to work on.

That being said, a good place to start would be this match statement:
https://github.com/sharkdp/fd/blob/27caa337296398d115f8779e08606897d8d9ad5e/src/walk.rs#L207-L210
where we currently silently ignore any errors by skipping to the next entry (return ignore::WalkState::Continue).

A really quick & dirty solution would be to add a print-statement here before returning. However, note that this part of the code runs in a parallelized way inside the "walker" threads (that do the actual work of finding files). Printing unsynchronized from these threads could potentially result in a messed-up terminal output.

A better way to fix this would be to send errors via the mpsc::channel that these worker threads use to communicate with the main thread. Currently, we use the channel to send PathBuf objects for every entry that fd finds. To extend this in such a way that we could alternatively send errors, we would probably write a new enum type along the lines of

enum WorkerResult {
  Entry(PathBuf),
  Error(SomeErrorType)
}

that could then by used as the underlying type for the mpsc::channel.

On the receiving side of the channel, we could then print the errors in a synchronized way from a single thread.

[psinghal20]

@sharkdp Thanks for your guidance. I tried doing it the 2nd way you mentioned, adding the WorkerResult enum which is sent to the main thread through the mpsc::channel. Please take a look at the PR #331 and suggest any changes, if required.

[sharkdp]

Closed via #331 by @psinghal20. Thanks!

[sharkdp]

Released in fd-7.2.0.

[HaleTom]

Totally sweet!! Thanks all! :)