Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Comments on Recursively remove files with the same name as the ones that end in `.part`

Parent

Recursively remove files with the same name as the ones that end in `.part`

+5
−0

I want to remove all files with the ".part" extension in the current directory and its subdirectories, including files with the same name but different extension.

Is this correct?

find . -name '*.part' -exec sh -c 'base="$(basename "$1" .part)"; find . -name "$base*" -delete' sh {} \;
History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+1
−0

I might be inclined to try...

find . -type f -name '*.part' -exec sh -c '
  [ -f "${1%.part}" ] && rm -i -- "${1%.part}"; 
  for f in "${1%.part}".*; do 
    [ -f "$f" ] && rm -i -- "$f"; 
  done
' -- {} \;

(newlines for readability; can be elided if one-liner means something to you...)

  1. find . -type f -name '*.part' — find files ending with .part
  2. -exec sh -c '...' -- {} \; — run a shell script ... for each found file; path to file is in $1 in child script
  3. "${1%.part}" — strip .part from the end of the filename in $1 (same as basename but without the extra process)
  4. [ -f "${1%.part}" ] && ...; — if a file exists with no extension, do the ... bit
  5. rm -i -- "${1%.part}" — delete the file with no extension
  6. for f in "${1%.part}".*; do ... done — loop each found path matching the filename with any extension; path is stored in $f (this includes the one with the .part extension)
  7. [ -f "$f" ] && ...; — if the path in $f exists and is a file, do the ... bit
  8. rm -i -- "$f" — remove the file in $f

Note that I'm using various checks that the thing I'm asking to delete is a file, not a directory, link, fifo, etc.

If limiting only to files is less of a concern, you might well be able to shorten this to...

find . -name '*.part' -exec sh -c 'rm -i -- "${1%.part}" "${1%.part}".*' -- {} \;

The shell may write errors if the args to rm don't expand to existing paths, hide that with judicious use of 2>/dev/null redirection, if you care.

For fewer subshells, you may be able to pass all found files to the same shell in one go, with...

find . -name '*.part' -exec sh -c 'while [ -n "$1" ]; do rm -i -- "${1%.part}" "${1%.part}".*; shift; done' -- {} \+

...but this might be painful for larger file lists.

In general, note there's is technically a race condition between the various tests and the eventual delete, but that's only a concern if multiple processes are acting on that directory tree. Not sure how to avoid that.

Finally, rm -i is used to prompt y/n for each file to delete, as a safety net. Remove the -i switch from the rm calls if you are confident.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Different interpretation of the problem (2 comments)
Different interpretation of the problem
Quasímodo‭ wrote 12 months ago

This provides a different interpretation of the problem (and I do not say this is a fault in the answer, only in that the question was not specific enough), namely that here ./abc.part results in the deletion of ./abc.foo but not ./d/abc.bar.

jimbobmcgee‭ wrote 12 months ago

Yes, that is true. I did make the assumption that the .part file would be specifically be a sibling to the files that were being deleted, which is not guaranteed by the question.