Bash function to find contents of a file with a certain extension












2














I have to read a lot of code and search through many code bases. I frequently find myself using something like grep -r --include=.C "test string" . to find files containing a certain string or regular expression. However, to simplify this and expedite the process, I want to create a function that allows me to specify what I am looking for, what are acceptable file extensions and what are inacceptable file extensions.



The function I have written is below. I am not sure if this follows best practices. Also, the hack using the brace expansion with the .? is bad. I really appreciate any feedback that you have.



findInFile() {
# Function to be placed in bash profile
# Allows user to specify what contents of a file they are looking for
# in what file types and in what NOT file types
# Iterate over the number of scripts arugments
# TODO: How can I create documentation for this function outside of code comments?
while [[ "$#" -gt 0 ]]
do
case $1 in
-ft|--fileTypes)
local fileTypes=$2
;;
-et|--excludeTypes)
local excludeTypes=$2
;;
*) # Catch the case where user does not specify
# these arguments
local searchTerm=$1
;;
esac
shift
done

echo "fileTypes: $fileTypes"
echo "excludeTypes: $excludeTypes"
echo "searchTerm: $searchTerm"

# TODO: Should probably clean up with case statement
# TODO: I am using this ? in the include and exclude as a hack
# to catch the case where only one file type is provided.
if [ -n "$fileTypes" ] && [ -n "$excludeTypes" ]
then
#searchString="grep -r --include=*{$fileTypes} --exclude=*{$excludeTypes} "$searchTerm" ."
searchString="grep -r --include=*{$fileTypes,.?} --exclude=*{$excludeTypes,.?} "$searchTerm" ."

elif [ -n "$fileTypes" ]
then
#searchString="grep -r --include=*{$fileTypes} "$searchTerm" ."
searchString="grep -r --include=*{$fileTypes,.?} "$searchTerm" ."
elif [ -n "$excludeTypes" ]
then
#searchString="grep -r --exclude=*{$excludeTypes} "$searchTerm" ."
searchString="grep -r --exclude=*{$excludeTypes,.?} "$searchTerm" ."
else
searchString="grep -r "$searchTerm" ."
fi

#searchString="grep -r --include=*{$fileTypes} "$searchTerm" ."
echo "searchString: $searchString"
eval $searchString

# TODO: Allow the user to type a number to then programmatically jump to that
# file in the text editor of their choice

}









share|improve this question







New contributor




ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • check out ack and its contemporaries, designed to solve your exact problem. grep -r --include=.C "test string" becomes ack --cc "test string" beyondgrep.com/feature-comparison beyondgrep.com/why-ack
    – Oh My Goodness
    Jan 4 at 1:10








  • 1




    You should have a look at ag, the silver searcher -- very fast, automatically recursive, PCRE regexes.
    – glenn jackman
    Jan 4 at 2:00












  • @glenn take a look at ripgrep 😀
    – hjpotter92
    Jan 4 at 5:52






  • 1




    I feel silly. All of these look like awesome options. I have been writing grep for years! This has been really helpful. Thank you everyone.
    – ML_Dev
    2 days ago
















2














I have to read a lot of code and search through many code bases. I frequently find myself using something like grep -r --include=.C "test string" . to find files containing a certain string or regular expression. However, to simplify this and expedite the process, I want to create a function that allows me to specify what I am looking for, what are acceptable file extensions and what are inacceptable file extensions.



The function I have written is below. I am not sure if this follows best practices. Also, the hack using the brace expansion with the .? is bad. I really appreciate any feedback that you have.



findInFile() {
# Function to be placed in bash profile
# Allows user to specify what contents of a file they are looking for
# in what file types and in what NOT file types
# Iterate over the number of scripts arugments
# TODO: How can I create documentation for this function outside of code comments?
while [[ "$#" -gt 0 ]]
do
case $1 in
-ft|--fileTypes)
local fileTypes=$2
;;
-et|--excludeTypes)
local excludeTypes=$2
;;
*) # Catch the case where user does not specify
# these arguments
local searchTerm=$1
;;
esac
shift
done

echo "fileTypes: $fileTypes"
echo "excludeTypes: $excludeTypes"
echo "searchTerm: $searchTerm"

# TODO: Should probably clean up with case statement
# TODO: I am using this ? in the include and exclude as a hack
# to catch the case where only one file type is provided.
if [ -n "$fileTypes" ] && [ -n "$excludeTypes" ]
then
#searchString="grep -r --include=*{$fileTypes} --exclude=*{$excludeTypes} "$searchTerm" ."
searchString="grep -r --include=*{$fileTypes,.?} --exclude=*{$excludeTypes,.?} "$searchTerm" ."

elif [ -n "$fileTypes" ]
then
#searchString="grep -r --include=*{$fileTypes} "$searchTerm" ."
searchString="grep -r --include=*{$fileTypes,.?} "$searchTerm" ."
elif [ -n "$excludeTypes" ]
then
#searchString="grep -r --exclude=*{$excludeTypes} "$searchTerm" ."
searchString="grep -r --exclude=*{$excludeTypes,.?} "$searchTerm" ."
else
searchString="grep -r "$searchTerm" ."
fi

#searchString="grep -r --include=*{$fileTypes} "$searchTerm" ."
echo "searchString: $searchString"
eval $searchString

# TODO: Allow the user to type a number to then programmatically jump to that
# file in the text editor of their choice

}









share|improve this question







New contributor




ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • check out ack and its contemporaries, designed to solve your exact problem. grep -r --include=.C "test string" becomes ack --cc "test string" beyondgrep.com/feature-comparison beyondgrep.com/why-ack
    – Oh My Goodness
    Jan 4 at 1:10








  • 1




    You should have a look at ag, the silver searcher -- very fast, automatically recursive, PCRE regexes.
    – glenn jackman
    Jan 4 at 2:00












  • @glenn take a look at ripgrep 😀
    – hjpotter92
    Jan 4 at 5:52






  • 1




    I feel silly. All of these look like awesome options. I have been writing grep for years! This has been really helpful. Thank you everyone.
    – ML_Dev
    2 days ago














2












2








2







I have to read a lot of code and search through many code bases. I frequently find myself using something like grep -r --include=.C "test string" . to find files containing a certain string or regular expression. However, to simplify this and expedite the process, I want to create a function that allows me to specify what I am looking for, what are acceptable file extensions and what are inacceptable file extensions.



The function I have written is below. I am not sure if this follows best practices. Also, the hack using the brace expansion with the .? is bad. I really appreciate any feedback that you have.



findInFile() {
# Function to be placed in bash profile
# Allows user to specify what contents of a file they are looking for
# in what file types and in what NOT file types
# Iterate over the number of scripts arugments
# TODO: How can I create documentation for this function outside of code comments?
while [[ "$#" -gt 0 ]]
do
case $1 in
-ft|--fileTypes)
local fileTypes=$2
;;
-et|--excludeTypes)
local excludeTypes=$2
;;
*) # Catch the case where user does not specify
# these arguments
local searchTerm=$1
;;
esac
shift
done

echo "fileTypes: $fileTypes"
echo "excludeTypes: $excludeTypes"
echo "searchTerm: $searchTerm"

# TODO: Should probably clean up with case statement
# TODO: I am using this ? in the include and exclude as a hack
# to catch the case where only one file type is provided.
if [ -n "$fileTypes" ] && [ -n "$excludeTypes" ]
then
#searchString="grep -r --include=*{$fileTypes} --exclude=*{$excludeTypes} "$searchTerm" ."
searchString="grep -r --include=*{$fileTypes,.?} --exclude=*{$excludeTypes,.?} "$searchTerm" ."

elif [ -n "$fileTypes" ]
then
#searchString="grep -r --include=*{$fileTypes} "$searchTerm" ."
searchString="grep -r --include=*{$fileTypes,.?} "$searchTerm" ."
elif [ -n "$excludeTypes" ]
then
#searchString="grep -r --exclude=*{$excludeTypes} "$searchTerm" ."
searchString="grep -r --exclude=*{$excludeTypes,.?} "$searchTerm" ."
else
searchString="grep -r "$searchTerm" ."
fi

#searchString="grep -r --include=*{$fileTypes} "$searchTerm" ."
echo "searchString: $searchString"
eval $searchString

# TODO: Allow the user to type a number to then programmatically jump to that
# file in the text editor of their choice

}









share|improve this question







New contributor




ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I have to read a lot of code and search through many code bases. I frequently find myself using something like grep -r --include=.C "test string" . to find files containing a certain string or regular expression. However, to simplify this and expedite the process, I want to create a function that allows me to specify what I am looking for, what are acceptable file extensions and what are inacceptable file extensions.



The function I have written is below. I am not sure if this follows best practices. Also, the hack using the brace expansion with the .? is bad. I really appreciate any feedback that you have.



findInFile() {
# Function to be placed in bash profile
# Allows user to specify what contents of a file they are looking for
# in what file types and in what NOT file types
# Iterate over the number of scripts arugments
# TODO: How can I create documentation for this function outside of code comments?
while [[ "$#" -gt 0 ]]
do
case $1 in
-ft|--fileTypes)
local fileTypes=$2
;;
-et|--excludeTypes)
local excludeTypes=$2
;;
*) # Catch the case where user does not specify
# these arguments
local searchTerm=$1
;;
esac
shift
done

echo "fileTypes: $fileTypes"
echo "excludeTypes: $excludeTypes"
echo "searchTerm: $searchTerm"

# TODO: Should probably clean up with case statement
# TODO: I am using this ? in the include and exclude as a hack
# to catch the case where only one file type is provided.
if [ -n "$fileTypes" ] && [ -n "$excludeTypes" ]
then
#searchString="grep -r --include=*{$fileTypes} --exclude=*{$excludeTypes} "$searchTerm" ."
searchString="grep -r --include=*{$fileTypes,.?} --exclude=*{$excludeTypes,.?} "$searchTerm" ."

elif [ -n "$fileTypes" ]
then
#searchString="grep -r --include=*{$fileTypes} "$searchTerm" ."
searchString="grep -r --include=*{$fileTypes,.?} "$searchTerm" ."
elif [ -n "$excludeTypes" ]
then
#searchString="grep -r --exclude=*{$excludeTypes} "$searchTerm" ."
searchString="grep -r --exclude=*{$excludeTypes,.?} "$searchTerm" ."
else
searchString="grep -r "$searchTerm" ."
fi

#searchString="grep -r --include=*{$fileTypes} "$searchTerm" ."
echo "searchString: $searchString"
eval $searchString

# TODO: Allow the user to type a number to then programmatically jump to that
# file in the text editor of their choice

}






bash shell






share|improve this question







New contributor




ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Jan 3 at 23:42









ML_Dev

485




485




New contributor




ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






ML_Dev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • check out ack and its contemporaries, designed to solve your exact problem. grep -r --include=.C "test string" becomes ack --cc "test string" beyondgrep.com/feature-comparison beyondgrep.com/why-ack
    – Oh My Goodness
    Jan 4 at 1:10








  • 1




    You should have a look at ag, the silver searcher -- very fast, automatically recursive, PCRE regexes.
    – glenn jackman
    Jan 4 at 2:00












  • @glenn take a look at ripgrep 😀
    – hjpotter92
    Jan 4 at 5:52






  • 1




    I feel silly. All of these look like awesome options. I have been writing grep for years! This has been really helpful. Thank you everyone.
    – ML_Dev
    2 days ago


















  • check out ack and its contemporaries, designed to solve your exact problem. grep -r --include=.C "test string" becomes ack --cc "test string" beyondgrep.com/feature-comparison beyondgrep.com/why-ack
    – Oh My Goodness
    Jan 4 at 1:10








  • 1




    You should have a look at ag, the silver searcher -- very fast, automatically recursive, PCRE regexes.
    – glenn jackman
    Jan 4 at 2:00












  • @glenn take a look at ripgrep 😀
    – hjpotter92
    Jan 4 at 5:52






  • 1




    I feel silly. All of these look like awesome options. I have been writing grep for years! This has been really helpful. Thank you everyone.
    – ML_Dev
    2 days ago
















check out ack and its contemporaries, designed to solve your exact problem. grep -r --include=.C "test string" becomes ack --cc "test string" beyondgrep.com/feature-comparison beyondgrep.com/why-ack
– Oh My Goodness
Jan 4 at 1:10






check out ack and its contemporaries, designed to solve your exact problem. grep -r --include=.C "test string" becomes ack --cc "test string" beyondgrep.com/feature-comparison beyondgrep.com/why-ack
– Oh My Goodness
Jan 4 at 1:10






1




1




You should have a look at ag, the silver searcher -- very fast, automatically recursive, PCRE regexes.
– glenn jackman
Jan 4 at 2:00






You should have a look at ag, the silver searcher -- very fast, automatically recursive, PCRE regexes.
– glenn jackman
Jan 4 at 2:00














@glenn take a look at ripgrep 😀
– hjpotter92
Jan 4 at 5:52




@glenn take a look at ripgrep 😀
– hjpotter92
Jan 4 at 5:52




1




1




I feel silly. All of these look like awesome options. I have been writing grep for years! This has been really helpful. Thank you everyone.
– ML_Dev
2 days ago




I feel silly. All of these look like awesome options. I have been writing grep for years! This has been really helpful. Thank you everyone.
– ML_Dev
2 days ago










1 Answer
1






active

oldest

votes


















1














You can use [[ .. ]] instead of [ .. ] to do tests. The former is a bash builtin and saves a fork.



You don't need to eval anything since you're just building a couple of optional switches to grep. Start with empty strings and populate variables or an array, and pass the result to an invocation of grep as variables. This also avoids enumerating every possible combination of arguments (already 4 combos with 2 options -- that approach quickly becomes unsustainable).



There's no need to absorb searchTerm. Just leave it in the arguments and pass all those to grep, which allows you to include grep switches too, like -i.



Use set +x to see what's going on.



Tying it all together:



findInFile() {
:<<_comment_
Function to be placed in bash profile
Allows user to specify what contents of a file they are looking for
in what file types and in what NOT file types
Iterate over the number of scripts arugments
_comment_
declare -a select
while [[ "$#" -gt 0 ]]
do
if [[ $1 =~ ^(-ft|--fileTypes|-et|--excludeTypes)$ ]]
then
local type="$2"
[[ "$type" == *,* ]] && type="{$type}"
if [[ $1 == *-f* ]]
then
select+=( "--include=*$type" )
else
select+=( "--exclude=*$type" )
fi
shift 2
else
break
fi
done
set -x
grep -r ${select[@]} "$@" .
{ set +x; } 2>/dev/null
}


You can include long comments as here-docs piped to the null operator :.






share|improve this answer





















    Your Answer





    StackExchange.ifUsing("editor", function () {
    return StackExchange.using("mathjaxEditing", function () {
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
    });
    });
    }, "mathjax-editing");

    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "196"
    };
    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
    });


    }
    });






    ML_Dev is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f210845%2fbash-function-to-find-contents-of-a-file-with-a-certain-extension%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    You can use [[ .. ]] instead of [ .. ] to do tests. The former is a bash builtin and saves a fork.



    You don't need to eval anything since you're just building a couple of optional switches to grep. Start with empty strings and populate variables or an array, and pass the result to an invocation of grep as variables. This also avoids enumerating every possible combination of arguments (already 4 combos with 2 options -- that approach quickly becomes unsustainable).



    There's no need to absorb searchTerm. Just leave it in the arguments and pass all those to grep, which allows you to include grep switches too, like -i.



    Use set +x to see what's going on.



    Tying it all together:



    findInFile() {
    :<<_comment_
    Function to be placed in bash profile
    Allows user to specify what contents of a file they are looking for
    in what file types and in what NOT file types
    Iterate over the number of scripts arugments
    _comment_
    declare -a select
    while [[ "$#" -gt 0 ]]
    do
    if [[ $1 =~ ^(-ft|--fileTypes|-et|--excludeTypes)$ ]]
    then
    local type="$2"
    [[ "$type" == *,* ]] && type="{$type}"
    if [[ $1 == *-f* ]]
    then
    select+=( "--include=*$type" )
    else
    select+=( "--exclude=*$type" )
    fi
    shift 2
    else
    break
    fi
    done
    set -x
    grep -r ${select[@]} "$@" .
    { set +x; } 2>/dev/null
    }


    You can include long comments as here-docs piped to the null operator :.






    share|improve this answer


























      1














      You can use [[ .. ]] instead of [ .. ] to do tests. The former is a bash builtin and saves a fork.



      You don't need to eval anything since you're just building a couple of optional switches to grep. Start with empty strings and populate variables or an array, and pass the result to an invocation of grep as variables. This also avoids enumerating every possible combination of arguments (already 4 combos with 2 options -- that approach quickly becomes unsustainable).



      There's no need to absorb searchTerm. Just leave it in the arguments and pass all those to grep, which allows you to include grep switches too, like -i.



      Use set +x to see what's going on.



      Tying it all together:



      findInFile() {
      :<<_comment_
      Function to be placed in bash profile
      Allows user to specify what contents of a file they are looking for
      in what file types and in what NOT file types
      Iterate over the number of scripts arugments
      _comment_
      declare -a select
      while [[ "$#" -gt 0 ]]
      do
      if [[ $1 =~ ^(-ft|--fileTypes|-et|--excludeTypes)$ ]]
      then
      local type="$2"
      [[ "$type" == *,* ]] && type="{$type}"
      if [[ $1 == *-f* ]]
      then
      select+=( "--include=*$type" )
      else
      select+=( "--exclude=*$type" )
      fi
      shift 2
      else
      break
      fi
      done
      set -x
      grep -r ${select[@]} "$@" .
      { set +x; } 2>/dev/null
      }


      You can include long comments as here-docs piped to the null operator :.






      share|improve this answer
























        1












        1








        1






        You can use [[ .. ]] instead of [ .. ] to do tests. The former is a bash builtin and saves a fork.



        You don't need to eval anything since you're just building a couple of optional switches to grep. Start with empty strings and populate variables or an array, and pass the result to an invocation of grep as variables. This also avoids enumerating every possible combination of arguments (already 4 combos with 2 options -- that approach quickly becomes unsustainable).



        There's no need to absorb searchTerm. Just leave it in the arguments and pass all those to grep, which allows you to include grep switches too, like -i.



        Use set +x to see what's going on.



        Tying it all together:



        findInFile() {
        :<<_comment_
        Function to be placed in bash profile
        Allows user to specify what contents of a file they are looking for
        in what file types and in what NOT file types
        Iterate over the number of scripts arugments
        _comment_
        declare -a select
        while [[ "$#" -gt 0 ]]
        do
        if [[ $1 =~ ^(-ft|--fileTypes|-et|--excludeTypes)$ ]]
        then
        local type="$2"
        [[ "$type" == *,* ]] && type="{$type}"
        if [[ $1 == *-f* ]]
        then
        select+=( "--include=*$type" )
        else
        select+=( "--exclude=*$type" )
        fi
        shift 2
        else
        break
        fi
        done
        set -x
        grep -r ${select[@]} "$@" .
        { set +x; } 2>/dev/null
        }


        You can include long comments as here-docs piped to the null operator :.






        share|improve this answer












        You can use [[ .. ]] instead of [ .. ] to do tests. The former is a bash builtin and saves a fork.



        You don't need to eval anything since you're just building a couple of optional switches to grep. Start with empty strings and populate variables or an array, and pass the result to an invocation of grep as variables. This also avoids enumerating every possible combination of arguments (already 4 combos with 2 options -- that approach quickly becomes unsustainable).



        There's no need to absorb searchTerm. Just leave it in the arguments and pass all those to grep, which allows you to include grep switches too, like -i.



        Use set +x to see what's going on.



        Tying it all together:



        findInFile() {
        :<<_comment_
        Function to be placed in bash profile
        Allows user to specify what contents of a file they are looking for
        in what file types and in what NOT file types
        Iterate over the number of scripts arugments
        _comment_
        declare -a select
        while [[ "$#" -gt 0 ]]
        do
        if [[ $1 =~ ^(-ft|--fileTypes|-et|--excludeTypes)$ ]]
        then
        local type="$2"
        [[ "$type" == *,* ]] && type="{$type}"
        if [[ $1 == *-f* ]]
        then
        select+=( "--include=*$type" )
        else
        select+=( "--exclude=*$type" )
        fi
        shift 2
        else
        break
        fi
        done
        set -x
        grep -r ${select[@]} "$@" .
        { set +x; } 2>/dev/null
        }


        You can include long comments as here-docs piped to the null operator :.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 4 at 1:53









        Oh My Goodness

        1813




        1813






















            ML_Dev is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            ML_Dev is a new contributor. Be nice, and check out our Code of Conduct.













            ML_Dev is a new contributor. Be nice, and check out our Code of Conduct.












            ML_Dev is a new contributor. Be nice, and check out our Code of Conduct.
















            Thanks for contributing an answer to Code Review 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.


            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • 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.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f210845%2fbash-function-to-find-contents-of-a-file-with-a-certain-extension%23new-answer', 'question_page');
            }
            );

            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







            Popular posts from this blog

            Сан-Квентин

            Алькесар

            Josef Freinademetz