Good Day,

On 10/20/18 11:32 AM, Richard Owlett wrote:
> I think my original post needs a rewrite ;/

Well, let's stick to the text then...

> I'm looking for a directory search tool with specific capabilities which 
> would fit comfortably with my work environment.
> 
> The "MATE Search Tool" comes close.
> It can:
>   Select a starting directory.

        $ find doc/

>   Search for a specific extension.

        $ find -iname '*.tex'

>   Search for a keyword in file content.

        $ find -exec grep -Eq "\<keyword\>" '{}' \; -print

> It cannot:
>    Search ONLY the specified directory.

        $ find -maxdepth 1

>    Return files that DO NOT contain a keyword.

        $ find -not -exec grep -Eq "\<keyword\>" '{}' \; -print

Putting it all together, that would give that sort of command:

        $ find doc/ \
        >       -maxdepth 1 \
        >       -iname "*.tex" \
        >       -not -exec grep -Eq "\<keyword\>" '{}' \; \
        >       -print

The order of search options is important, as each one refines
a bit more the search field among the files.

> "ls" can search by extension and stay in specified directory but not
> include/exclude keywords.

"ls" is good for listing directory content.  "find" is designed
to find files on their inode information (name, last modification
date, size, that kind of stuff).  As soon as you need to deal
with text inside that file, you also need to include execution
of commands designed to read the file and return or not in error
depending on the presence of keywords: "grep" is such a command.

> I suspect that what I want would most likely be a command line too> Perhaps a 
> script will be required. But, before reinventing the wheel, I ask "Does an 
> appropriate command already exist?"

Yes, "find" as command line, will do the job.

> [My immediate problem involves only a couple dozen files so a manual search 
> is feasible.]
> 
> My take away from answers so far is "A script will be required."

Not necessarily, the trouble is: "find" is so vast, you can
spend hours in the manual to search for adequate option for
your specific need, and end up writing a script, instead of
having found "the proper option".

> As I am exploring Tcl/Tk and this tool would provide input to a current Tcl 
> project, I will use it rather than bash.

Note that at no moment Bash has been mentioned.  You could
have launched all these "find" instances from an exec() call
in whatever language you with to use.  :-)

> Thank you.

Kind Regards,
-- 
Étienne Mollier <etienne.moll...@mailoo.org>

Reply via email to