Bash script to find files with a string in the title and print them and ask to delete them
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 and then prompt the user if they want to delete it.
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 course.
And this worked until I realized it had to list each one separately then prompt to delete them which is a bit of problem since the previous two lines of code just do all the matching files at once.
shell-script
edited 34 mins ago
Rui F Ribeiro
40.1k1479136
asked Apr 10 '16 at 4:32
user276019user276019
1
add a comment |
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 and then prompt the user if they want to delete it.
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 course.
And this worked until I realized it had to list each one separately then prompt to delete them which is a bit of problem since the previous two lines of code just do all the matching files at once.
shell-script
edited 34 mins ago
Rui F Ribeiro
40.1k1479136
asked Apr 10 '16 at 4:32
user276019user276019
1
add a comment |
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 and then prompt the user if they want to delete it.
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 course.
And this worked until I realized it had to list each one separately then prompt to delete them which is a bit of problem since the previous two lines of code just do all the matching files at once.
shell-script
edited 34 mins ago
Rui F Ribeiro
40.1k1479136
asked Apr 10 '16 at 4:32
user276019user276019
1
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 and then prompt the user if they want to delete it.
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 course.
And this worked until I realized it had to list each one separately then prompt to delete them which is a bit of problem since the previous two lines of code just do all the matching files at once.
shell-script
shell-script
edited 34 mins ago
Rui F Ribeiro
40.1k1479136
asked Apr 10 '16 at 4:32
user276019user276019
1
edited 34 mins ago
Rui F Ribeiro
40.1k1479136
asked Apr 10 '16 at 4:32
user276019user276019
1
edited 34 mins ago
Rui F Ribeiro
40.1k1479136
edited 34 mins ago
Rui F Ribeiro
40.1k1479136
edited 34 mins ago
Rui F Ribeiro
40.1k1479136
40.1k1479136
asked Apr 10 '16 at 4:32
user276019user276019
1
asked Apr 10 '16 at 4:32
user276019user276019
1
asked Apr 10 '16 at 4:32
user276019user276019
1
1
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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 {} +
answered 12 mins ago
KusalanandaKusalananda
129k16244402
add a comment |
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.
answered Apr 10 '16 at 4:44
MelBurslanMelBurslan
5,29811533
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
Apr 10 '16 at 4:53
1
Don’t dofor file in $(find …); do …; dofind "$dir" -type f -name "*${pattern}*" -exec rm -i {} +. Note that$dirshould be quoted (in double quotes); putting it in braces accomplishes nothing.
– G-Man
Apr 10 '16 at 5:31
1
@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 usingfor file in $(find ...). Usefind ... -exec rm -i {} +as he suggested orfind ... | 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 (whileloop) works for all filenames except those with newlines. These are not matters of opinion, they are facts.
– cas
Apr 10 '16 at 8:49
2
Don't read lines withfor
– glenn jackman
Apr 10 '16 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.
– G-Man
Apr 11 '16 at 5:35
|
show 4 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f275443%2fbash-script-to-find-files-with-a-string-in-the-title-and-print-them-and-ask-to-d%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 {} +
answered 12 mins ago
KusalanandaKusalananda
129k16244402
add a comment |
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 {} +
answered 12 mins ago
KusalanandaKusalananda
129k16244402
add a comment |
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 {} +
answered 12 mins ago
KusalanandaKusalananda
129k16244402
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 {} +
answered 12 mins ago
KusalanandaKusalananda
129k16244402
edited 5 mins ago
answered 12 mins ago
KusalanandaKusalananda
129k16244402
answered 12 mins ago
KusalanandaKusalananda
129k16244402
answered 12 mins ago
KusalanandaKusalananda
129k16244402
129k16244402
add a comment |
add a comment |
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.
answered Apr 10 '16 at 4:44
MelBurslanMelBurslan
5,29811533
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
Apr 10 '16 at 4:53
1
Don’t dofor file in $(find …); do …; dofind "$dir" -type f -name "*${pattern}*" -exec rm -i {} +. Note that$dirshould be quoted (in double quotes); putting it in braces accomplishes nothing.
– G-Man
Apr 10 '16 at 5:31
1
@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 usingfor file in $(find ...). Usefind ... -exec rm -i {} +as he suggested orfind ... | 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 (whileloop) works for all filenames except those with newlines. These are not matters of opinion, they are facts.
– cas
Apr 10 '16 at 8:49
2
Don't read lines withfor
– glenn jackman
Apr 10 '16 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.
– G-Man
Apr 11 '16 at 5:35
|
show 4 more comments
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.
answered Apr 10 '16 at 4:44
MelBurslanMelBurslan
5,29811533
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
Apr 10 '16 at 4:53
1
Don’t dofor file in $(find …); do …; dofind "$dir" -type f -name "*${pattern}*" -exec rm -i {} +. Note that$dirshould be quoted (in double quotes); putting it in braces accomplishes nothing.
– G-Man
Apr 10 '16 at 5:31
1
@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 usingfor file in $(find ...). Usefind ... -exec rm -i {} +as he suggested orfind ... | 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 (whileloop) works for all filenames except those with newlines. These are not matters of opinion, they are facts.
– cas
Apr 10 '16 at 8:49
2
Don't read lines withfor
– glenn jackman
Apr 10 '16 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.
– G-Man
Apr 11 '16 at 5:35
|
show 4 more comments
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.
answered Apr 10 '16 at 4:44
MelBurslanMelBurslan
5,29811533
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.
answered Apr 10 '16 at 4:44
MelBurslanMelBurslan
5,29811533
answered Apr 10 '16 at 4:44
MelBurslanMelBurslan
5,29811533
answered Apr 10 '16 at 4:44
MelBurslanMelBurslan
5,29811533
answered Apr 10 '16 at 4:44
MelBurslanMelBurslan
5,29811533
5,29811533
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
Apr 10 '16 at 4:53
1
Don’t dofor file in $(find …); do …; dofind "$dir" -type f -name "*${pattern}*" -exec rm -i {} +. Note that$dirshould be quoted (in double quotes); putting it in braces accomplishes nothing.
– G-Man
Apr 10 '16 at 5:31
1
@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 usingfor file in $(find ...). Usefind ... -exec rm -i {} +as he suggested orfind ... | 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 (whileloop) works for all filenames except those with newlines. These are not matters of opinion, they are facts.
– cas
Apr 10 '16 at 8:49
2
Don't read lines withfor
– glenn jackman
Apr 10 '16 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.
– G-Man
Apr 11 '16 at 5:35
|
show 4 more comments
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
Apr 10 '16 at 4:53
1
Don’t dofor file in $(find …); do …; dofind "$dir" -type f -name "*${pattern}*" -exec rm -i {} +. Note that$dirshould be quoted (in double quotes); putting it in braces accomplishes nothing.
– G-Man
Apr 10 '16 at 5:31
1
@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 usingfor file in $(find ...). Usefind ... -exec rm -i {} +as he suggested orfind ... | 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 (whileloop) works for all filenames except those with newlines. These are not matters of opinion, they are facts.
– cas
Apr 10 '16 at 8:49
2
Don't read lines withfor
– glenn jackman
Apr 10 '16 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.
– G-Man
Apr 11 '16 at 5:35
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
Apr 10 '16 at 4:53
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
Apr 10 '16 at 4:53
1
1
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.– G-Man
Apr 10 '16 at 5:31
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.– G-Man
Apr 10 '16 at 5:31
1
1
@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
Apr 10 '16 at 8:49
@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
Apr 10 '16 at 8:49
2
2
Don't read lines with
for– glenn jackman
Apr 10 '16 at 11:56
Don't read lines with
for– glenn jackman
Apr 10 '16 at 11:56
1
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.– G-Man
Apr 11 '16 at 5:35
(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.– G-Man
Apr 11 '16 at 5:35
|
show 4 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f275443%2fbash-script-to-find-files-with-a-string-in-the-title-and-print-them-and-ask-to-d%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
