Open jreisinger opened 2 years ago
Thanks, @jreisinger! Yes, that seems a reasonable expectation.
It seems like FindFiles should just ignore any errors encountered by filepath.Walk
. I think while we're working on that, it would make sense to update FindFiles to use fs.WalkDir instead of filepath.Walk
, wouldn't it? Then it would be easier to test (see Walking with filesystems).
@bitfield agree that using fs.WalkDir
with fs.SkipDir
would provide a nice DX here.
Thinking that we'd still want to include the permission errors in the output though (rather than completely swallowing), as this is more aligned with the default behavior of find
?
Maybe checking to see if the fs.WalkDirFunc returns fs.ErrPermission
, and if so, append <path-to-file>: permission denied
to filenames. Otherwise if any other err type is encountered, it should be piped out WithError.
The developer could always just Reject lines containing "permission denied"
from the resulting pipe of a successful find.
@parkerduckworth it's a tricky area, because one of the design goals for script
is to just get out of your way so that you can cook up quick hacks, and in the event of errors it should just "do the right thing", without blocking your task.
Ah, ok. Understood
On Mar 27, 2022, at 4:43 AM, John Arundel @.***> wrote:
@parkerduckworth it's a tricky area, because one of the design goals for script is to just get out of your way so that you can cook up quick hacks, and in the event of errors it should just "do the right thing", without blocking your task.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
Happy to accept PRs for this.
@bitfield great, just submitted one
@bitfield what's the status of this? i'd be happy to pick it up if it still needs fixing
This program
yields:
I expected behavior similar to
find $HOME -type f
, i.e. to return files from directories it can open.