2

I need to make a bash script that takes two arguments, one is the string to search for in the filenames and the next one is the file path to search in. Next it needs to go through one matching file at a time and print it out, then prompt the user if they want to delete it or not.

An example of it would be:

./scriptName.sh foo /path/to/directory/

/path/to/directory/foo.txt

Delete this? (y/n)

user input

/path/to/directory/foop.txt

Delete this? (y/n)

user input

etc...

I originally tried

find $2 -type f -name "*$1*" -print

and

find $2 -type f -name "*$1*" -delete

Where $1 is the first argument and $2 are the second argument of the script.

This worked until I realized that it had to list each found file separately and prompt to delete them which is a bit of problem since the previous two lines of code just deletes all the matching files at once.

2 Answers 2

2

You could either use -ok to execute rm on the found pathnames, or use -exec to execute rm -i.

This shows short examples of each, and assumes that $searchpath is the search path and $pattern is the final name pattern (e.g. "*$1*").

Using -ok: The -ok action of find is similar to -exec, but it asks the user for confirmation first, before executing the given utility. We use it to execute rm on each found pathname individually.

find "$searchpath" -type f -name "$pattern" -ok rm {} \;

Using rm -i: This would make the rm utility itself ask for confirmation before removing a file. We can use this on batches of pathnames.

find "$searchpath" -type f -name "$pattern" -exec rm -i {} +

You could obviously implement your own prompting too. Here's a bash script that prompts for deletion of the single file at "$pathname":

read -p "Delete the file at $pathname? y/[n]: "
[[ "$REPLY" == [yY]* ]] && rm "$pathname"

Calling this from find for batches of pathnames:

find "$searchpath" -type f -name "$pattern" -exec bash -c '
    for pathname do
        read -p "Delete the file at $pathname? y/[n]: "
        [[ "$REPLY" == [yY]* ]] && rm "$pathname"
    done' bash {} +

If the user replies with a string starting with an upper or lower cased y, the file will be deleted.

Related:

-2
pattern=$1
dir=$2

for file in $(find ${dir} -type f -name "*${pattern}*")
do
  /bin/rm -i ${file}
done

Basically you are looping through the files the find command returns and rm -i command is asking you a y/n question to delete the file or not. I think it is what you are looking for but if not, let people know what your exact need is for further help.

9
  • thank you for your help, I'm sure I can figure it out myself but the major part of this is the prompt to the user to decide whether or not to delete the file. Can I put this between the do done?
    – user276019
    Commented Apr 10, 2016 at 4:53
  • 2
    Don’t do for file in $(find …); do …; do find "$dir" -type f -name "*${pattern}*" -exec rm -i {} +. Note that $dir should be quoted (in double quotes); putting it in braces accomplishes nothing. Commented Apr 10, 2016 at 5:31
  • 2
    @G-Man is correct. in this particular case, the braces, while harmless, do nothing of any use, but double-quoting the variables would protect against embedded spaces and other problem characters. He's also correct about not using for file in $(find ...). Use find ... -exec rm -i {} + as he suggested or find ... | while IFS= read file ; do rm -i "$file" ; done. The former (-exec rm) works for all files, even those with newlines in the filename, whereas the second (while loop) works for all filenames except those with newlines. These are not matters of opinion, they are facts.
    – cas
    Commented Apr 10, 2016 at 8:49
  • 3
    Don't read lines with for Commented Apr 10, 2016 at 11:56
  • 1
    (Cont’d) …  You say, “at the most unexpected moment, they (braces) save you a lot of headache …”  I’m going to disagree with that.  If you use $foo_bar (or even "$foo_bar") when you meant ${foo}_bar (or "${foo}_bar" or "$foo"_bar), i.e., you want the value of $foo + the literal string _bar, and you do any testing, you will discover your error immediately.  But if you use $foo (or even ${foo}) when you meant "$foo" (or "${foo}"), that error will cause you a lot of headache at the most unexpected moment; when you encounter a filename with special character(s) in it. Commented Apr 11, 2016 at 5:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .