Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #201440 > unrolled thread

An appropriate directory search tool?

Back to article view | Back to linux.debian.user

Contents

  An appropriate directory search tool? Richard Owlett <rowlett@cloud85.net> - 2018-10-19 17:10 +0200
    Re: An appropriate directory search tool? Roberto C. Sánchez <roberto@debian.org> - 2018-10-19 17:20 +0200
    Re: An appropriate directory search tool? Roberto C. Sánchez <roberto@debian.org> - 2018-10-19 17:20 +0200
    Re: An appropriate directory search tool? <tomas@tuxteam.de> - 2018-10-19 17:30 +0200
      Re: An appropriate directory search tool? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-19 17:40 +0200
        Re: An appropriate directory search tool? <tomas@tuxteam.de> - 2018-10-19 17:50 +0200
        Re: An appropriate directory search tool? rhkramer@gmail.com - 2018-10-20 15:30 +0200
    Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-10-19 17:50 +0200
      Re: An appropriate directory search tool? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-19 18:10 +0200
        Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-10-30 16:00 +0100
          Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-12-01 18:20 +0100
    Re: An appropriate directory search tool? songbird <songbird@anthive.com> - 2018-10-20 00:40 +0200
    Re: An appropriate directory search tool? Richard Owlett <rowlett@cloud85.net> - 2018-10-20 11:40 +0200
      Re: An appropriate directory search tool? <tomas@tuxteam.de> - 2018-10-20 11:50 +0200
        Re: An appropriate directory search tool? Richard Owlett <rowlett@cloud85.net> - 2018-10-20 12:30 +0200
          Re: An appropriate directory search tool? Joe <joe@jretrading.com> - 2018-10-20 13:40 +0200
            Re: An appropriate directory search tool? Richard Owlett <rowlett@cloud85.net> - 2018-10-20 14:30 +0200
              Re: An appropriate directory search tool? Brian <ad44@cityscape.co.uk> - 2018-10-20 21:10 +0200
                Re: An appropriate directory search tool? Håkon Alstadheim <hakon@alstadheim.priv.no> - 2018-10-21 00:00 +0200
                  Re: An appropriate directory search tool? Richard Owlett <rowlett@cloud85.net> - 2018-10-21 12:10 +0200
                Re: An appropriate directory search tool? Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-10-21 11:00 +0200
                  Re: An appropriate directory search tool? <tomas@tuxteam.de> - 2018-10-21 11:20 +0200
          Re: An appropriate directory search tool? Roberto C. Sánchez <roberto@debian.org> - 2018-10-20 14:10 +0200
          Re: An appropriate directory search tool? John Crawley <john@bunsenlabs.org> - 2018-10-21 03:20 +0200
            Re: An appropriate directory search tool? mick crane <mick.crane@gmail.com> - 2018-10-21 07:30 +0200
            Re: An appropriate directory search tool? Richard Owlett <rowlett@cloud85.net> - 2018-10-21 12:30 +0200
              Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-10-21 15:50 +0200
                Re: An appropriate directory search tool? rhkramer@gmail.com - 2018-10-21 16:40 +0200
                  Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-10-21 17:30 +0200
                    Re: An appropriate directory search tool? rhkramer@gmail.com - 2018-10-21 17:50 +0200
                      Re: An appropriate directory search tool? Curt <curty@free.fr> - 2018-10-21 18:40 +0200
                      Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-10-21 18:40 +0200
                        Re: An appropriate directory search tool? rhkramer@gmail.com - 2018-10-21 19:20 +0200
                          Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-10-21 21:00 +0200
                            Re: An appropriate directory search tool? rhkramer@gmail.com - 2018-10-21 23:50 +0200
                Re: An appropriate directory search tool? John Crawley <john@bunsenlabs.org> - 2018-10-22 03:20 +0200
                  Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-10-22 17:30 +0200
                Re: An appropriate directory search tool? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-22 15:20 +0200
                  Re: An appropriate directory search tool? David Wright <deblis@lionunicorn.co.uk> - 2018-10-22 17:30 +0200
                    Re: An appropriate directory search tool? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-22 17:50 +0200
          Re: An appropriate directory search tool? Curt <curty@free.fr> - 2018-10-21 12:00 +0200
        Re: An appropriate directory search tool? Joe <joe@jretrading.com> - 2018-10-20 13:30 +0200
          Re: An appropriate directory search tool? Richard Owlett <rowlett@cloud85.net> - 2018-10-20 14:30 +0200
      Re: An appropriate directory search tool? Étienne Mollier <etienne.mollier@mailoo.org> - 2018-10-20 12:30 +0200
        Re: An appropriate directory search tool? Richard Owlett <rowlett@cloud85.net> - 2018-10-20 14:40 +0200
          Re: An appropriate directory search tool? Dan Purgert <dan@djph.net> - 2018-10-20 15:20 +0200
          Re: An appropriate directory search tool? rhkramer@gmail.com - 2018-10-20 15:30 +0200

Page 1 of 3  [1] 2 3  Next page →

#201440 — An appropriate directory search tool?

The "MATE Search Tool" comes close.

It can:
   Select a starting directory.
   Search for a specific extension.
   Search for a keyword in file content.

It cannot:
    Search ONLY the specified directory.
    Return files that DO NOT contain a keyword.

I suspect what I want would most likely be what I'm looking for.
"ls" can search by extension and stay in specified directory.
It cannot include/exclude keywords.

My immediate problem involves only a couple dozen files so manual search 
is feasible.

Suggestions?
TIA

[toc] | [next] | [standalone]

#201441

On Fri, Oct 19, 2018 at 11:12:30AM -0400, Roberto C. Sánchez wrote:
> On Fri, Oct 19, 2018 at 10:00:25AM -0500, Richard Owlett wrote:
> > The "MATE Search Tool" comes close.
> > 
> > It can:
> >   Select a starting directory.
> >   Search for a specific extension.
> >   Search for a keyword in file content.
> > 
I missed your keyword search requirement.

> > It cannot:
> >    Search ONLY the specified directory.
> >    Return files that DO NOT contain a keyword.
> > 
> > I suspect what I want would most likely be what I'm looking for.
> > "ls" can search by extension and stay in specified directory.
> > It cannot include/exclude keywords.
> > 
> > My immediate problem involves only a couple dozen files so manual search is
> > feasible.
> > 
> > Suggestions?
> 
> I recommend 'find' run from the terminal.
> 
> For example, I have a directory tree full of files like shell scripts,
> Perl scripts, and also XML documents and their Russian translations.  To
> find the XML documents that are not Russian translations, I can do this:
> 
> find . -name '*.xml' -a \! -name '*_ru.xml'
> 
I would modify the above command like this:

find . -name '*.xml' -a \! -name '*_ru.xml' -exec grep -Hn '<year>2003-2005</year>' {} \;

> Read that as "find, the current director, files named *.xml and not
> named *_ru.xml."
> 
Which would then change the reading to "find, the current director,
files named *.xml and not named *_ru.xml that contains the string
'<year>2003-2005</year>'." (the -Hn options to grep tell it to display
the file name and line number of each match)

> It also supports an amazing array of conditions, like newer/older than,
> same/different permissions, size, etc.
> 
> Regards,
> 
> -Roberto
> -- 
> Roberto C. Sánchez
> 

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#201442

On Fri, Oct 19, 2018 at 10:00:25AM -0500, Richard Owlett wrote:
> The "MATE Search Tool" comes close.
> 
> It can:
>   Select a starting directory.
>   Search for a specific extension.
>   Search for a keyword in file content.
> 
> It cannot:
>    Search ONLY the specified directory.
>    Return files that DO NOT contain a keyword.
> 
> I suspect what I want would most likely be what I'm looking for.
> "ls" can search by extension and stay in specified directory.
> It cannot include/exclude keywords.
> 
> My immediate problem involves only a couple dozen files so manual search is
> feasible.
> 
> Suggestions?

I recommend 'find' run from the terminal.

For example, I have a directory tree full of files like shell scripts,
Perl scripts, and also XML documents and their Russian translations.  To
find the XML documents that are not Russian translations, I can do this:

find . -name '*.xml' -a \! -name '*_ru.xml'

Read that as "find, the current director, files named *.xml and not
named *_ru.xml."

It also supports an amazing array of conditions, like newer/older than,
same/different permissions, size, etc.

Regards,

-Roberto
-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#201443

[Multipart message — attachments visible in raw view] — view raw

On Fri, Oct 19, 2018 at 10:00:25AM -0500, Richard Owlett wrote:
> The "MATE Search Tool" comes close.
> 
> It can:
>   Select a starting directory.
>   Search for a specific extension.
>   Search for a keyword in file content.
> 
> It cannot:
>    Search ONLY the specified directory.
>    Return files that DO NOT contain a keyword.
> 
> I suspect what I want would most likely be what I'm looking for.
> "ls" can search by extension and stay in specified directory.
> It cannot include/exclude keywords.
> 
> My immediate problem involves only a couple dozen files so manual
> search is feasible.
> 
> Suggestions?

This would be 'find' (ok, with some little help from 'grep'). Hands down.

The man page can be a bit... intimidating, so I'd suggest to begin with
little examples and return to the man page from time to time until you
got the knack. Then it is worth it. Every bit.

To help you get started, I cooked up something implementing your "It
cannot" above. Here's the (commented) shell session:

  # Set lab rats up:
  tomas@trotzki:~$ mkdir d1 d1/d2
  tomas@trotzki:~$ cd d1
  tomas@trotzki:~/d1$ for f in f1 f2 f4 f6 d2/f1 d2/f2 ; do echo "hello world" > $f ; done
  tomas@trotzki:~/d1$ for f in f3 f5 d2/f3 ; do echo "wello horld" > $f ; done
  # Find all files containing the string "hell", limiting search
  # to one level of subdirectories (i.e. current dir, i.e. "d1"):
  tomas@trotzki:~/d1$ find . -maxdepth 1 -type f \( -exec grep -q "hell" {} \; -o -print \)
  ./f5
  ./f3
  # Same, but dropping the limit to one level:
  tomas@trotzki:~/d1$ find . -type f \( -exec grep -q "hell" {} \; -o -print \)
  ./d2/f3
  ./f5
  ./f3

Hope that tickled your curiosity :-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#201445

On Fri, Oct 19, 2018 at 05:21:30PM +0200, tomas@tuxteam.de wrote:
> This would be 'find' (ok, with some little help from 'grep'). Hands down.
> 
> The man page can be a bit... intimidating, so I'd suggest to begin with
> little examples and return to the man page from time to time until you
> got the knack. Then it is worth it. Every bit.

There's also <https://mywiki.wooledge.org/UsingFind>.

[toc] | [prev] | [next] | [standalone]

#201447

[Multipart message — attachments visible in raw view] — view raw

On Fri, Oct 19, 2018 at 11:29:13AM -0400, Greg Wooledge wrote:
> On Fri, Oct 19, 2018 at 05:21:30PM +0200, tomas@tuxteam.de wrote:
> > This would be 'find' (ok, with some little help from 'grep'). Hands down.
> > 
> > The man page can be a bit... intimidating [...]

> There's also <https://mywiki.wooledge.org/UsingFind>.

Had a short look at it. Definitely recommended.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#201488

On Friday, October 19, 2018 11:29:13 AM Greg Wooledge wrote:
> There's also <https://mywiki.wooledge.org/UsingFind>.

I'm not the OP, but I wanted to say that I find the pages on your wiki (at 
least the ones I've looked at) to be helpful and well-written.

[toc] | [prev] | [next] | [standalone]

#201446

On Fri 19 Oct 2018 at 10:00:25 (-0500), Richard Owlett wrote:
> The "MATE Search Tool" comes close.
> 
> It can:
>   Select a starting directory.
>   Search for a specific extension.
>   Search for a keyword in file content.
> 
> It cannot:
>    Search ONLY the specified directory.
>    Return files that DO NOT contain a keyword.
> 
> I suspect what I want would most likely be what I'm looking for.
> "ls" can search by extension and stay in specified directory.
> It cannot include/exclude keywords.
> 
> My immediate problem involves only a couple dozen files so manual
> search is feasible.

Recalling https://lists.debian.org/debian-user/2018/09/msg00228.html
as others have said, get familiar with find.

I keep a number of potted searches for different occasions as the
syntax can be a bit overwhelming. Here are a few:

find . -type f | while read file ; do bash-function "$file"; done # avoid using exec
find . -type f -exec chmod a-wx {} \;
find . -type f -size 1234c -print | less # size in bytes
find . -type f -mmin -1440 -print | less # one day
find . -type f -exec file {} \; | less
find . -type f -name \*ly -printf '%TY-%Tm-%Td %TT %f\n' | cut --complement -b 20-30 | sort
find . -type f -name \*ly -exec grep -Z -l -i 'x' {} \; | sort -z | xargs -0 less # display files
find . -type f -name \*ly -exec grep -H -i 'x' {} \; | sort | less # display lines

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#201448

On Fri, Oct 19, 2018 at 10:48:42AM -0500, David Wright wrote:
> find . -type f -exec chmod a-wx {} \;

For this one, you probably want to replace \; with + to get the efficiency
boost, which would be pretty significant here.  You probably wrote this
one a long time ago.

> find . -type f | while read file ; do bash-function "$file"; done # avoid using exec

This one has a few minor bugs.  It will fail on filenames that contain
newlines, or backslashes, or trailing whitespace, or leading whitespace.
It can be corrected, although sadly the corrected version is a bit uglier.

find . -type f -print0 | while IFS= read -rd '' file; do bash-function "$file"; done

> find . -type f -name \*ly -printf '%TY-%Tm-%Td %TT %f\n' | cut --complement -b 20-30 | sort

This one looks like a variant of my "rlart" function:

rlart() {
  find "${1:-.}" -type f -printf '%T@,%TY-%Tm-%Td,%TT,%p\0' |
  sort -zn |
  while IFS=, read -rd '' _ day time path; do
    printf '%s %s %s\n' "$day" "${time%.*}" "$path"
  done
}

I give a detailed explanation of an earlier iteration of that one on
<https://mywiki.wooledge.org/BashProgramming/03> for those who are
interested in that sort of thing.  The explicit comma delimiters were
added more recently, to avoid losing trailing whitespace.

[toc] | [prev] | [next] | [standalone]

#201885

On Fri 19 Oct 2018 at 12:03:42 (-0400), Greg Wooledge wrote:
> On Fri, Oct 19, 2018 at 10:48:42AM -0500, David Wright wrote:
> > find . -type f -exec chmod a-wx {} \;
> 
> For this one, you probably want to replace \; with + to get the efficiency
> boost, which would be pretty significant here.  You probably wrote this
> one a long time ago.

You're dead right. It could even have been copied straight from Unix
Power Tools 1st ed. And, of course, with the other example
find . -type f -exec file {} \; | less
it can make a huge difference to the number of "find: ‘file’
terminated by signal 13" messages if you lose interest and quit
out of less.

> > find . -type f | while read file ; do bash-function "$file"; done # avoid using exec
> 
> This one has a few minor bugs.  It will fail on filenames that contain
> newlines, or backslashes, or trailing whitespace, or leading whitespace.
> It can be corrected, although sadly the corrected version is a bit uglier.
> 
> find . -type f -print0 | while IFS= read -rd '' file; do bash-function "$file"; done

Updated. I'm more careful in writing my bash functions than this
commandline¹ stuff where the filename population tends to be
more restricted (ie I generated them).

> > find . -type f -name \*ly -printf '%TY-%Tm-%Td %TT %f\n' | cut --complement -b 20-30 | sort
> 
> This one looks like a variant of my "rlart" function:
> 
> rlart() {
>   find "${1:-.}" -type f -printf '%T@,%TY-%Tm-%Td,%TT,%p\0' |
>   sort -zn |
>   while IFS=, read -rd '' _ day time path; do
>     printf '%s %s %s\n' "$day" "${time%.*}" "$path"
>   done
> }
> 
> I give a detailed explanation of an earlier iteration of that one on
> <https://mywiki.wooledge.org/BashProgramming/03> for those who are
> interested in that sort of thing.  The explicit comma delimiters were
> added more recently, to avoid losing trailing whitespace.

Again, as you can see from -name, they're intended for particular sets
of files. Your considered version is better, so updated. However, I've
added back name so that just a set of source files are considered
(-name \*py might be a more obvious example for others) and I throw
away the leading directories.

Thanks once again for preening my bash constructs; much appreciated.

¹ I'm probably unusual in having a readonly .bash_history which
contains a handcrafted set of command paradigms. That's why some of
my commandlines might seem inordinately long, like hundreds of chars.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#202943

On Tue 30 Oct 2018 at 09:52:52 (-0500), David Wright wrote:
> On Fri 19 Oct 2018 at 12:03:42 (-0400), Greg Wooledge wrote:
> > On Fri, Oct 19, 2018 at 10:48:42AM -0500, David Wright wrote:
> > > find . -type f -exec chmod a-wx {} \;
> > 
> > For this one, you probably want to replace \; with + to get the efficiency
> > boost, which would be pretty significant here.  You probably wrote this
> > one a long time ago.
> 
> You're dead right. It could even have been copied straight from Unix
> Power Tools 1st ed. And, of course, with the other example
> find . -type f -exec file {} \; | less
> it can make a huge difference to the number of "find: ‘file’
> terminated by signal 13" messages if you lose interest and quit
> out of less.

[…]

> Updated. I'm more careful in writing my bash functions than this
> commandline¹ stuff where the filename population tends to be
> more restricted (ie I generated them).

… and so I was running my eyes over my .bashrc file to see if there
were any similar constructions that had survived over the years and
could do with updating. In doing so, I came across examples where
a little extra thought is required:

    find "$@" -depth -xdev -type d -empty -ok rmdir {} \;
    find "$@" -depth -xdev -type d -empty -print -exec rmdir {} \;

Using + in the second example won't work correctly.

There's a warning in   man find   about the potential of + to
short-circuit running all the commands in case of error, but
perhaps it should also warn of the dangers of mixing + and -depth.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#201452

Richard Owlett wrote:
...
> I suspect what I want would most likely be what I'm looking for.
> "ls" can search by extension and stay in specified directory.
> It cannot include/exclude keywords.
>
> My immediate problem involves only a couple dozen files so manual search 
> is feasible.
>
> Suggestions?

  use and indexing system for text files.  use find for 
file names.

  there are already existing indexing/lookup systems
out there but i'm not looking for them...  that's your
homework.  ;)


  songbird

[toc] | [prev] | [next] | [standalone]

#201469

I think my original post needs a rewrite ;/

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.
   Search for a specific extension.
   Search for a keyword in file content.
It cannot:
    Search ONLY the specified directory.
    Return files that DO NOT contain a keyword.

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

I suspect that what I want would most likely be a command line tool.
Perhaps a script will be required. But, before reinventing the wheel, I 
ask "Does an appropriate command already exist?"
[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."
As I am exploring Tcl/Tk and this tool would provide input to a current 
Tcl project, I will use it rather than bash.

Thank you.

[toc] | [prev] | [next] | [standalone]

#201470

[Multipart message — attachments visible in raw view] — view raw

On Sat, Oct 20, 2018 at 04:32:43AM -0500, Richard Owlett wrote:
> I think my original post needs a rewrite ;/
> 
> I'm looking for a directory search tool with specific capabilities
> which would fit comfortably with my work environment.

[...]

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

[...]

Judging by your (second) post, I get the feeling that the answers
given in this list haven't reached you (at whatever level). Most
of them were quite positive: "yes, such a tool exists, it's called
'find'", some of them even implemented a sketch of a solution to
your concrete example.

Since you don't even try to make reference to *any* of the numerous
proposals flung around here, I'm at a loss on how to help you.

For now, I'll just give up, sorry.

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#201472

On 10/20/2018 04:44 AM, tomas@tuxteam.de wrote:
> On Sat, Oct 20, 2018 at 04:32:43AM -0500, Richard Owlett wrote:
>> I think my original post needs a rewrite ;/
>>
>> I'm looking for a directory search tool with specific capabilities
>> which would fit comfortably with my work environment.
> 
> [...]
> 
>> I suspect that what I want would most likely be a command line tool.
>> Perhaps a script will be required. But, before reinventing the
>> wheel, I ask "Does an appropriate command already exist?"
> 
> [...]
> 
> Judging by your (second) post, I get the feeling that the answers
> given in this list haven't reached you (at whatever level).

But they did.
That's why I wrote 'My take away from answers so far is "A script will 
be required." '
Perhaps we have different ideas of the definition of "script".
I saw the examples which worked as scripts (even if written as one 
liners). If I had attempted to use bash, I would have expected to use an 
explicit pipe command between 'find' and 'grep'.


> Most
> of them were quite positive: "yes, such a tool exists, it's called
> 'find'", some of them even implemented a sketch of a solution to
> your concrete example.
> 
> Since you don't even try to make reference to *any* of the numerous
> proposals flung around here, I'm at a loss on how to help you.
> 
> For now, I'll just give up, sorry.
> 
> Cheers
> -- tomás
> 

[toc] | [prev] | [next] | [standalone]

#201475

On Sat, 20 Oct 2018 05:28:52 -0500
Richard Owlett <rowlett@cloud85.net> wrote:

> On 10/20/2018 04:44 AM, tomas@tuxteam.de wrote:
> > On Sat, Oct 20, 2018 at 04:32:43AM -0500, Richard Owlett wrote:  
> >> I think my original post needs a rewrite ;/
> >>
> >> I'm looking for a directory search tool with specific capabilities
> >> which would fit comfortably with my work environment.  
> > 
> > [...]
> >   
> >> I suspect that what I want would most likely be a command line
> >> tool. Perhaps a script will be required. But, before reinventing
> >> the wheel, I ask "Does an appropriate command already exist?"  
> > 
> > [...]
> > 
> > Judging by your (second) post, I get the feeling that the answers
> > given in this list haven't reached you (at whatever level).  
> 
> But they did.
> That's why I wrote 'My take away from answers so far is "A script
> will be required." '
> Perhaps we have different ideas of the definition of "script".
> I saw the examples which worked as scripts (even if written as one 
> liners). If I had attempted to use bash, I would have expected to use
> an explicit pipe command between 'find' and 'grep'.
> 

Have you looked at 'zenity' for (somewhat) graphicising scripts? Not
quite the full GUI experience, but quick and dirty.

https://www.linuxjournal.com/content/make-your-scripts-user-friendly-zenity
-- 
Joe

[toc] | [prev] | [next] | [standalone]

#201481

On 10/20/2018 06:37 AM, Joe wrote:
> On Sat, 20 Oct 2018 05:28:52 -0500
> Richard Owlett <rowlett@cloud85.net> wrote:
> 
>> On 10/20/2018 04:44 AM, tomas@tuxteam.de wrote:
>>> On Sat, Oct 20, 2018 at 04:32:43AM -0500, Richard Owlett wrote:
>>>> I think my original post needs a rewrite ;/
>>>>
>>>> I'm looking for a directory search tool with specific capabilities
>>>> which would fit comfortably with my work environment.
>>>
>>> [...]
>>>    
>>>> I suspect that what I want would most likely be a command line
>>>> tool. Perhaps a script will be required. But, before reinventing
>>>> the wheel, I ask "Does an appropriate command already exist?"
>>>
>>> [...]
>>>
>>> Judging by your (second) post, I get the feeling that the answers
>>> given in this list haven't reached you (at whatever level).
>>
>> But they did.
>> That's why I wrote 'My take away from answers so far is "A script
>> will be required." '
>> Perhaps we have different ideas of the definition of "script".
>> I saw the examples which worked as scripts (even if written as one
>> liners). If I had attempted to use bash, I would have expected to use
>> an explicit pipe command between 'find' and 'grep'.
>>
> 
> Have you looked at 'zenity' for (somewhat) graphicising scripts? Not
> quite the full GUI experience, but quick and dirty.
> 
> https://www.linuxjournal.com/content/make-your-scripts-user-friendly-zenity
> 

Had never heard of 'zenity'.
I browsed the text of the page. To read it as intended I'll have to use 
an alternate profile -- it expects "features" I've explicitly disabled.

I searched for 'zenity tutorials'. The first few I found encourage 
further investigation.

[toc] | [prev] | [next] | [standalone]

#201493

On Sat 20 Oct 2018 at 07:19:50 -0500, Richard Owlett wrote:

> On 10/20/2018 06:37 AM, Joe wrote:
> > On Sat, 20 Oct 2018 05:28:52 -0500
> > Richard Owlett <rowlett@cloud85.net> wrote:
> > 
> > > On 10/20/2018 04:44 AM, tomas@tuxteam.de wrote:
> > > > On Sat, Oct 20, 2018 at 04:32:43AM -0500, Richard Owlett wrote:
> > > > > I think my original post needs a rewrite ;/
> > > > > 
> > > > > I'm looking for a directory search tool with specific capabilities
> > > > > which would fit comfortably with my work environment.
> > > > 
> > > > [...]
> > > > > I suspect that what I want would most likely be a command line
> > > > > tool. Perhaps a script will be required. But, before reinventing
> > > > > the wheel, I ask "Does an appropriate command already exist?"
> > > > 
> > > > [...]
> > > > 
> > > > Judging by your (second) post, I get the feeling that the answers
> > > > given in this list haven't reached you (at whatever level).
> > > 
> > > But they did.
> > > That's why I wrote 'My take away from answers so far is "A script
> > > will be required." '
> > > Perhaps we have different ideas of the definition of "script".
> > > I saw the examples which worked as scripts (even if written as one
> > > liners). If I had attempted to use bash, I would have expected to use
> > > an explicit pipe command between 'find' and 'grep'.
> > > 
> > 
> > Have you looked at 'zenity' for (somewhat) graphicising scripts? Not
> > quite the full GUI experience, but quick and dirty.
> > 
> > https://www.linuxjournal.com/content/make-your-scripts-user-friendly-zenity
> > 
> 
> Had never heard of 'zenity'.
> I browsed the text of the page. To read it as intended I'll have to use an
> alternate profile -- it expects "features" I've explicitly disabled.
> 
> I searched for 'zenity tutorials'. The first few I found encourage further
> investigation.

I'd stay awy from zenity if I were you. The same advice applies to yad.
As for dialog - don't go near it. You will be a lot happier.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#201494

Den 20. okt. 2018 21:05, skrev Brian:
> On Sat 20 Oct 2018 at 07:19:50 -0500, Richard Owlett wrote:
>
>> On 10/20/2018 06:37 AM, Joe wrote:
>>> On Sat, 20 Oct 2018 05:28:52 -0500
>>> Richard Owlett <rowlett@cloud85.net> wrote:
>>>
>>>> On 10/20/2018 04:44 AM, tomas@tuxteam.de wrote:
>>>>> On Sat, Oct 20, 2018 at 04:32:43AM -0500, Richard Owlett wrote:
>>>>>> I think my original post needs a rewrite ;/
>>>>>>
>>>>>> I'm looking for a directory search tool with specific capabilities
>>>>>> which would fit comfortably with my work environment.
>>>>> [...]
>>>>>> I suspect that what I want would most likely be a command line
>>>>>> tool. Perhaps a script will be required. But, before reinventing
>>>>>> the wheel, I ask "Does an appropriate command already exist?"
>>>>> [...]
>>>>>
>>>>> Judging by your (second) post, I get the feeling that the answers
>>>>> given in this list haven't reached you (at whatever level).
>>>> But they did.
>>>> That's why I wrote 'My take away from answers so far is "A script
>>>> will be required." '
>>>> Perhaps we have different ideas of the definition of "script".
>>>> I saw the examples which worked as scripts (even if written as one
>>>> liners). If I had attempted to use bash, I would have expected to use
>>>> an explicit pipe command between 'find' and 'grep'.
>>>>
>>> Have you looked at 'zenity' for (somewhat) graphicising scripts? Not
>>> quite the full GUI experience, but quick and dirty.
>>>
>>> https://www.linuxjournal.com/content/make-your-scripts-user-friendly-zenity
>>>
>> Had never heard of 'zenity'.
>> I browsed the text of the page. To read it as intended I'll have to use an
>> alternate profile -- it expects "features" I've explicitly disabled.
>>
>> I searched for 'zenity tutorials'. The first few I found encourage further
>> investigation.
> I'd stay awy from zenity if I were you. The same advice applies to yad.
> As for dialog - don't go near it. You will be a lot happier.
>
If you want some interacivity-support for your find, emacs (and most
other coding-editors I suppose) can run find and let you pick through
the results in an editing-buffer. In emacs it is M-x find-dired, which
lets you pick the directory under which to search, hit enter, and then
enter the search criteria for find, and hit enter. If you want grep with
that, you do M-x find-grep-dired, and input directory and search-string
to look for INSIDE the files found. When you hit enter after the
criteria, it will show the results in a buffer, an you can hit enter on
any of the results to open that file.

[toc] | [prev] | [next] | [standalone]

#201501

On 10/20/2018 04:57 PM, Håkon Alstadheim wrote:
> 
> 
> Den 20. okt. 2018 21:05, skrev Brian:
>> On Sat 20 Oct 2018 at 07:19:50 -0500, Richard Owlett wrote:
>>
>>> On 10/20/2018 06:37 AM, Joe wrote:
>>>> On Sat, 20 Oct 2018 05:28:52 -0500
>>>> Richard Owlett <rowlett@cloud85.net> wrote:
>>>>
>>>>> On 10/20/2018 04:44 AM, tomas@tuxteam.de wrote:
>>>>>> On Sat, Oct 20, 2018 at 04:32:43AM -0500, Richard Owlett wrote:
>>>>>>> I think my original post needs a rewrite ;/
>>>>>>>
>>>>>>> I'm looking for a directory search tool with specific capabilities
>>>>>>> which would fit comfortably with my work environment.
>>>>>> [...]
>>>>>>> I suspect that what I want would most likely be a command line
>>>>>>> tool. Perhaps a script will be required. But, before reinventing
>>>>>>> the wheel, I ask "Does an appropriate command already exist?"
>>>>>> [...]
>>>>>>
>>>>>> Judging by your (second) post, I get the feeling that the answers
>>>>>> given in this list haven't reached you (at whatever level).
>>>>> But they did.
>>>>> That's why I wrote 'My take away from answers so far is "A script
>>>>> will be required." '
>>>>> Perhaps we have different ideas of the definition of "script".
>>>>> I saw the examples which worked as scripts (even if written as one
>>>>> liners). If I had attempted to use bash, I would have expected to use
>>>>> an explicit pipe command between 'find' and 'grep'.
>>>>>
>>>> Have you looked at 'zenity' for (somewhat) graphicising scripts? Not
>>>> quite the full GUI experience, but quick and dirty.
>>>>
>>>> https://www.linuxjournal.com/content/make-your-scripts-user-friendly-zenity
>>>>
>>> Had never heard of 'zenity'.
>>> I browsed the text of the page. To read it as intended I'll have to use an
>>> alternate profile -- it expects "features" I've explicitly disabled.
>>>
>>> I searched for 'zenity tutorials'. The first few I found encourage further
>>> investigation.
>> I'd stay awy from zenity if I were you. The same advice applies to yad.
>> As for dialog - don't go near it. You will be a lot happier.
>>
> If you want some interacivity-support for your find, emacs (and most
> other coding-editors I suppose) can run find and let you pick through
> the results in an editing-buffer. In emacs it is M-x find-dired, which
> lets you pick the directory under which to search, hit enter, and then
> enter the search criteria for find, and hit enter. If you want grep with
> that, you do M-x find-grep-dired, and input directory and search-string
> to look for INSIDE the files found. When you hit enter after the
> criteria, it will show the results in a buffer, an you can hit enter on
> any of the results to open that file.
> 

Emacs is on my todo list. Last time it was suggested, I discovered it is 
related to TECO which I had used 40 years ago. It could do just about 
anything.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web