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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#201498

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

On 21/10/18 06:05, Brian wrote:
> On Sat 20 Oct 2018 at 07:19:50 -0500, Richard Owlett wrote:
>> 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.

Zenity looks pretty ordinary.  Lots of output to terminal, chose
random date, saw as follows:


$ zenity --calendar --text='When is your birthday?' --title='Example 1'

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:154:27: The style property GtkButton:image-spacing is
deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:155:26: The style property GtkButton:inner-border is
deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:584:27: The style property GtkButton:image-spacing is
deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:585:28: The style property GtkWidget:interior-focus is
deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:586:28: The style property GtkButton:default-border is
deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:587:26: The style property GtkButton:inner-border is
deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:1344:25: The style property GtkRange:slider-width is
deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:1345:25: The style property GtkRange:stepper-size is
deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:1347:28: The style property GtkRange:stepper-spacing
is deprecated and shouldn't be used anymore. It will be removed in a
future version

(zenity:28755): Gtk-WARNING **: Theme parsing error:
gtk-widgets.css:1348:34: The style property
GtkRange:trough-under-steppers is deprecated and shouldn't be used
anymore. It will be removed in a future version
Gtk-Message: GtkDialog mapped without a transient parent. This is
discouraged.
25/10/18


Cheers
A
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8w+JQAKCRCoFmvLt+/i
+4xwAQDVkeoD6fTPiv60pYDuwJB0fg2ZW8YIUW1gt2sGvwC+HQD+Mjp5JdaF/kez
KBCN3t8QIsSWeymUYP4Uh/zgXox95GM=
=5Wsf
-----END PGP SIGNATURE-----

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

#201499

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

On Sun, Oct 21, 2018 at 07:51:55PM +1100, Andrew McGlashan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> On 21/10/18 06:05, Brian wrote:
> > On Sat 20 Oct 2018 at 07:19:50 -0500, Richard Owlett wrote:
> >> 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.
> 
> Zenity looks pretty ordinary.  Lots of output to terminal, chose
> random date, saw as follows:

I used zenity to build the GUI for a mini-application (basically a
front end for a semi-fixed rsync powered backup).

My take? Slow, inflexible, heavy dependencies footprint.

After that experience I fell back to use Tcl/Tk for that kind of
thing. My users love it.

Cheers
-- t

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

#201477

On Sat, Oct 20, 2018 at 05:28:52AM -0500, Richard Owlett wrote:
> 
> 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'.
> 
While you can certainly do that, the authors find were clearly aware
that the "find one or more files based on some criteria and then perform
one or more operations on those files" would be a common enough workflow
that they included the -exec and -execdir options to find.  With those
you do not need a pipe between find and grep.  It also effectively deals
with the situation where the file list is so long that you exceed the
system limit for the length of a command line.  The -exec option will
perform the specified action once per file found that meets the
criteria, where the pipe approach would pass the entire output of find
into the grep command.  That is sometimes not what you want.

However, if you still want to use the pipe approach, I would advise you
to look at the -print0 option to find and the -0 option to xargs.  Since
the normal find output is one file name per line and since newlines are
valid in file names, it may sometimes not yield the expected result.  A
NULL character, however, is not valid in a filename, so it is an
effective separator and you can use it like this:

find <dir-or-dirs> <criteria> -print0 | xargs -0 <cmd> <cmd-opts>

That will ensure that you actually get the result you expect and as a
bonus xargs handles the "do this command once for each input line"
dance, so you are not likely to exceed the system limit on the length of
a command line.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#201495

On 20/10/2018 19.28, Richard Owlett wrote:
> ...I would have expected to use an 
> explicit pipe command between 'find' and 'grep'.

In fact, depending on the exact conditions of your search, you might not 
need to use find at all. 'grep -r' will do a recursive search, starting 
at whatever directory you give it, looking inside every file for some 
content. Like:

grep -r 'keyword_or_regex' dirname

Of course, 'man grep' for various options...

-- 
John

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

#201497

On 2018-10-21 02:16, John Crawley wrote:
> On 20/10/2018 19.28, Richard Owlett wrote:
>> ...I would have expected to use an explicit pipe command between 
>> 'find' and 'grep'.
> 
> In fact, depending on the exact conditions of your search, you might
> not need to use find at all. 'grep -r' will do a recursive search,
> starting at whatever directory you give it, looking inside every file
> for some content. Like:
> 
> grep -r 'keyword_or_regex' dirname
> 
> Of course, 'man grep' for various options...

certainly grep especially if you can't remember where you put something.
If it's just filenames then I like 'locate' as it seems quick once the 
database is updated.
apart from the default look "everywhere" there's

"updatedb -o db_file -U source_directory"

"locate -i -d db_file text_to_look_for"

"-i" ignores case

as an aside there is so much to try to understand about how this stuff 
is organised and all the syntax for bash, perl and the useful provided 
software that you can spend a great deal of time there. Especially if 
you are a little bit elderly perhaps better to be familiar with just the 
things you need to get your project done.

mick






-- 
Key ID    4BFEBB31

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

#201502

On 10/20/2018 08:16 PM, John Crawley wrote:
> On 20/10/2018 19.28, Richard Owlett wrote:
>> ...I would have expected to use an explicit pipe command between 
>> 'find' and 'grep'.
> 
> In fact, depending on the exact conditions of your search, you might not 
> need to use find at all. 'grep -r' will do a recursive search, starting 
> at whatever directory you give it, looking inside every file for some 
> content. Like:
> 
> grep -r 'keyword_or_regex' dirname
> 
> Of course, 'man grep' for various options...
> 

I wish a list of files with a specific extension in a directory which 
contain keywordA but not keywordB. Recursing down the directory tree was 
the primary objection to the MATE search tool.

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

#201505

On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
> On 10/20/2018 08:16 PM, John Crawley wrote:
> > On 20/10/2018 19.28, Richard Owlett wrote:
> > > ...I would have expected to use an explicit pipe command
> > > between 'find' and 'grep'.
> > 
> > In fact, depending on the exact conditions of your search, you
> > might not need to use find at all. 'grep -r' will do a recursive
> > search, starting at whatever directory you give it, looking inside
> > every file for some content. Like:
> > 
> > grep -r 'keyword_or_regex' dirname
> > 
> > Of course, 'man grep' for various options...
> > 
> 
> I wish a list of files with a specific extension in a directory which
> contain keywordA but not keywordB. Recursing down the directory tree
> was the primary objection to the MATE search tool.

At last, a direct question!

$ grep -L keywordB $(grep -l keywordA a-directory/*extension)

Mix with quotes according to taste and needs.

Cheers,
David.

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

#201508

On Sunday, October 21, 2018 09:48:28 AM David Wright wrote:
> On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
> > I wish a list of files with a specific extension in a directory which
> > contain keywordA but not keywordB. Recursing down the directory tree
> > was the primary objection to the MATE search tool.
> 
> At last, a direct question!
> 
> $ grep -L keywordB $(grep -l keywordA a-directory/*extension)

I am not the OP, and I haven't tried this out, but, reading the grep man page 
for the -L (and the -l) option, I'm a little concerned by the sentence that 
says ~"Scanning will stop on the first match" -- does that mean it will stop 
scanning the particular file being scanned, or does that mean it will stop 
scanning in the directory (or list of files) being scanned?

I guess I should assume you know what you're doing, but I am uncertain what 
the man page is telling me.

> 
> Mix with quotes according to taste and needs.

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

#201511

On Sun 21 Oct 2018 at 10:33:41 (-0400), rhkramer@gmail.com wrote:
> On Sunday, October 21, 2018 09:48:28 AM David Wright wrote:
> > On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
> > > I wish a list of files with a specific extension in a directory which
> > > contain keywordA but not keywordB. Recursing down the directory tree
> > > was the primary objection to the MATE search tool.
> > 
> > At last, a direct question!
> > 
> > $ grep -L keywordB $(grep -l keywordA a-directory/*extension)
> 
> I am not the OP, and I haven't tried this out, but, reading the grep man page 
> for the -L (and the -l) option, I'm a little concerned by the sentence that 
> says ~"Scanning will stop on the first match" -- does that mean it will stop 
> scanning the particular file being scanned, or does that mean it will stop 
> scanning in the directory (or list of files) being scanned?

Read the full names of the options:
--files-without-match
--files-with-matches
      ↑

But the fact that scaanning stops can be important. When you get to
test it out for yourself, try using interactive standard input (-)
as an input file and you will see the difference when you add -l
as an option.

Cheers,
David.

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

#201512

On Sunday, October 21, 2018 11:21:35 AM David Wright wrote:
> On Sun 21 Oct 2018 at 10:33:41 (-0400), rhkramer@gmail.com wrote:
> > On Sunday, October 21, 2018 09:48:28 AM David Wright wrote:
> > > $ grep -L keywordB $(grep -l keywordA a-directory/*extension)
> > 
> > I am not the OP, and I haven't tried this out, but, reading the grep man
> > page for the -L (and the -l) option, I'm a little concerned by the
> > sentence that says ~"Scanning will stop on the first match" -- does that
> > mean it will stop scanning the particular file being scanned, or does
> > that mean it will stop scanning in the directory (or list of files)
> > being scanned?
> 
> Read the full names of the options:
> --files-without-match
> --files-with-matches
>       ↑
> 
> But the fact that scaanning stops can be important. When you get to
> test it out for yourself, try using interactive standard input (-)
> as an input file and you will see the difference when you add -l
> as an option.

Thanks for the reply, and I like that ability to use standard input!

I tried the following, and the output from -L and -l seems almost the same, 
except for that extra line that says "(standard input)" when I use the -l 
option.
 
Any further clarification / clues would be appreciated.

<quote>
rhk@s19:/rhk/ked1$ grep -l test -
one
two
test
(standard input)
rhk@s19:/rhk/ked1$ grep -L test -
test
rhk@s19:/rhk/ked1$ grep -L test -
one
two
test
rhk@s19:/rhk/ked1$ grep -l test -
one
two
test
(standard input)
rhk@s19:/rhk/ked1$
</quote>

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

#201513

On 2018-10-21, rhkramer@gmail.com <rhkramer@gmail.com> wrote:
>
> Thanks for the reply, and I like that ability to use standard input!
>
> I tried the following, and the output from -L and -l seems almost the same, 
> except for that extra line that says "(standard input)" when I use the -l 
> option.
  
For -l, I guess grep's returning the "file" (standard input) when the first match is
found (as per the man page).

For -L, I guess it will keep going until you give it test, at which point it stops,
returning nothing (stops at the first non-match).

We'll wait for more informed theories to follow.

> Any further clarification / clues would be appreciated.
>
><quote>
> rhk@s19:/rhk/ked1$ grep -l test -
> one
> two
> test
> (standard input)
> rhk@s19:/rhk/ked1$ grep -L test -
> test
> rhk@s19:/rhk/ked1$ grep -L test -
> one
> two
> test
> rhk@s19:/rhk/ked1$ grep -l test -
> one
> two
> test
> (standard input)
> rhk@s19:/rhk/ked1$
></quote>
>
>
>


-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

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

#201514

On Sun 21 Oct 2018 at 11:45:49 (-0400), rhkramer@gmail.com wrote:
> On Sunday, October 21, 2018 11:21:35 AM David Wright wrote:
> > On Sun 21 Oct 2018 at 10:33:41 (-0400), rhkramer@gmail.com wrote:
> > > On Sunday, October 21, 2018 09:48:28 AM David Wright wrote:
> > > > $ grep -L keywordB $(grep -l keywordA a-directory/*extension)
> > > 
> > > I am not the OP, and I haven't tried this out, but, reading the grep man
> > > page for the -L (and the -l) option, I'm a little concerned by the
> > > sentence that says ~"Scanning will stop on the first match" -- does that
> > > mean it will stop scanning the particular file being scanned, or does
> > > that mean it will stop scanning in the directory (or list of files)
> > > being scanned?
> > 
> > Read the full names of the options:
> > --files-without-match
> > --files-with-matches
> >       ↑
> > 
> > But the fact that scaanning stops can be important. When you get to
> > test it out for yourself, try using interactive standard input (-)
> > as an input file and you will see the difference when you add -l
> > as an option.
> 
> Thanks for the reply, and I like that ability to use standard input!
> 
> I tried the following, and the output from -L and -l seems almost the same, 
> except for that extra line that says "(standard input)" when I use the -l 
> option.
>  
> Any further clarification / clues would be appreciated.

Use neither option to see the difference with using either -l or -L.
So that standard output doesn't clutter the output, I suggest
redirecting it thus:

$ grep test - >| /tmp/a ; echo "and the output is" ; cat /tmp/a

Then you will see the difference when you add -l as an option.

Cheers,
David.

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

#201515

On Sunday, October 21, 2018 12:35:04 PM David Wright wrote:
> On Sun 21 Oct 2018 at 11:45:49 (-0400), rhkramer@gmail.com wrote:
> > Any further clarification / clues would be appreciated.
> 
> Use neither option to see the difference with using either -l or -L.
> So that standard output doesn't clutter the output, I suggest
> redirecting it thus:
> 
> $ grep test - >| /tmp/a ; echo "and the output is" ; cat /tmp/a
> 
> Then you will see the difference when you add -l as an option.

Ok, thanks again, to you and Curt!

I see the difference, but it may take a little while for it to really soak in 
(and / or to recognize a use / need for it (for me)), but I guess I learned 
something ;-)

It sort of looks like that, with the -l option, if there were additonal files 
that also had matches, I might have to restart the command to find others, but, 
I'm not sure of that, and I guess I'd have to run a more extensive  test to 
confirm that, like creating at least two files with matches and put them in a 
directory (probably with some other files that don't match).

I'm not ready to do that at the moment, so I'll leave it there for now.

(And, I doubt there's a way to run the same command using standard input twice 
(e.g., something like grep test - - ...).)

For anyone else who is interested, my tests are shown below:

<quote>
rhk@s19:/rhk/ked1$ grep test - >| /tmp/a ; echo "and the output is" ; cat 
/tmp/a
one
two
test
one
two
test
^C
rhk@s19:/rhk/ked1$ less  /tmp/a
rhk@s19:/rhk/ked1$ grep -l test - >| /tmp/a ; echo "and the output is" ; cat 
/tmp/a
one
two
test
and the output is
(standard input)
rhk@s19:/rhk/ked1$ grep -L test - >| /tmp/a ; echo "and the output is" ; cat 
/tmp/a
one
two
test
and the output is
rhk@s19:/rhk/ked1$ 
</quote>

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

#201518

On Sun 21 Oct 2018 at 13:11:16 (-0400), rhkramer@gmail.com wrote:
> On Sunday, October 21, 2018 12:35:04 PM David Wright wrote:
> > On Sun 21 Oct 2018 at 11:45:49 (-0400), rhkramer@gmail.com wrote:
> > > Any further clarification / clues would be appreciated.
> > 
> > Use neither option to see the difference with using either -l or -L.
> > So that standard output doesn't clutter the output, I suggest
> > redirecting it thus:
> > 
> > $ grep test - >| /tmp/a ; echo "and the output is" ; cat /tmp/a
> > 
> > Then you will see the difference when you add -l as an option.
> 
> Ok, thanks again, to you and Curt!
> 
> I see the difference, but it may take a little while for it to really soak in 
> (and / or to recognize a use / need for it (for me)), but I guess I learned 
> something ;-)
> 
> It sort of looks like that, with the -l option, if there were additonal files 
> that also had matches, I might have to restart the command to find others, but, 
> I'm not sure of that, and I guess I'd have to run a more extensive  test to 
> confirm that, like creating at least two files with matches and put them in a 
> directory (probably with some other files that don't match).
> 
> I'm not ready to do that at the moment, so I'll leave it there for now.
> 
> (And, I doubt there's a way to run the same command using standard input twice 
> (e.g., something like grep test - - ...).)
> 
> For anyone else who is interested, my tests are shown below:
> 
> <quote>
> rhk@s19:/rhk/ked1$ grep test - >| /tmp/a ; echo "and the output is" ; cat /tmp/a
> one
> two
> test
> one
> two
> test
> ^C
> rhk@s19:/rhk/ked1$ less  /tmp/a
> rhk@s19:/rhk/ked1$

^C is not the way to exit stdin; you should use ^D, like logging out.
Unfortunately ^C has also lost you the contents of /tmp/a as the
buffer wasn't flushed. (Use cat, rather than less, so we all see it.)
In addition, if there are any filenames following - (stdin), it will
also skip those. With ^D instead, those files will all be inspected
in the same way, in regular order, to see if they any matching lines.
No restarting required.

> rhk@s19:/rhk/ked1$ grep -l test - >| /tmp/a ; echo "and the output is" ; cat /tmp/a
> one
> two
> test
> and the output is
> (standard input)
> rhk@s19:/rhk/ked1$

But now you can see that the succesful match meant that you didn't
have to keep typing any more stdin because it was closed for you
immediately after the match.

That's the idea of "short-circuit" operations; once a match is found
in a file, the rest of it doesn't have to be read, however long the
file is. That's a useful, but non-essential, efficiency.

But the warning is also necessary because you have to think about the
process that's feeding stdin (when it's not you typing it in). That
process might have expected stdin to remain open and writable much
longer than it did, perhaps only closing it when *it* had finished
doing whatever.

Cheers,
David.

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

#201519

On Sunday, October 21, 2018 02:52:15 PM David Wright wrote:
> On Sun 21 Oct 2018 at 13:11:16 (-0400), rhkramer@gmail.com wrote:
> > <quote>
> > rhk@s19:/rhk/ked1$ grep test - >| /tmp/a ; echo "and the output is" ; cat
> > /tmp/a one
> > two
> > test
> > one
> > two
> > test
> > ^C
> > rhk@s19:/rhk/ked1$ less  /tmp/a
> > rhk@s19:/rhk/ked1$
> 
> ^C is not the way to exit stdin; you should use ^D, like logging out.
> Unfortunately ^C has also lost you the contents of /tmp/a as the
> buffer wasn't flushed. (Use cat, rather than less, so we all see it.)
> In addition, if there are any filenames following - (stdin), it will
> also skip those. With ^D instead, those files will all be inspected
> in the same way, in regular order, to see if they any matching lines.
> No restarting required.

Ok, here is the new test (using ^D)::

<quote>
rhk@s19:/rhk/ked1$ grep test - >| /tmp/a ; echo "and the output is" ; cat 
/tmp/a
one 
two
three
test
one 
two
test
and the output is
test
test
rhk@s19:/rhk/ked1$ 
</quote>

> 
> > rhk@s19:/rhk/ked1$ grep -l test - >| /tmp/a ; echo "and the output is" ;
> > cat /tmp/a one
> > two
> > test
> > and the output is
> > (standard input)
> > rhk@s19:/rhk/ked1$
> 
> But now you can see that the succesful match meant that you didn't
> have to keep typing any more stdin because it was closed for you
> immediately after the match.
> 
> That's the idea of "short-circuit" operations; once a match is found
> in a file, the rest of it doesn't have to be read, however long the
> file is. That's a useful, but non-essential, efficiency.
> 
> But the warning is also necessary because you have to think about the
> process that's feeding stdin (when it's not you typing it in). That
> process might have expected stdin to remain open and writable much
> longer than it did, perhaps only closing it when *it* had finished
> doing whatever.

Thanks -- more to absorb ;-)

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

#201521

On 21/10/2018 22.48, David Wright wrote:
> On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
>> On 10/20/2018 08:16 PM, John Crawley wrote:
>>> On 20/10/2018 19.28, Richard Owlett wrote:
>>>> ...I would have expected to use an explicit pipe command
>>>> between 'find' and 'grep'.
>>>
>>> In fact, depending on the exact conditions of your search, you
>>> might not need to use find at all. 'grep -r' will do a recursive
>>> search, starting at whatever directory you give it, looking inside
>>> every file for some content. Like:
>>>
>>> grep -r 'keyword_or_regex' dirname
>>>
>>> Of course, 'man grep' for various options...
>>>
>>
>> I wish a list of files with a specific extension in a directory which
>> contain keywordA but not keywordB. Recursing down the directory tree
>> was the primary objection to the MATE search tool.
> 
> At last, a direct question!
> 
> $ grep -L keywordB $(grep -l keywordA a-directory/*extension)
> 
> Mix with quotes according to taste and needs.

I'm pretty sure David's code above will do exactly what the OP asked for.

This is about searching through a list of files, so I think the  
subsequent discussion of stdin might have been a bit confusing, since  
it's only one file.

The -L and -l options are about what grep outputs: the name of a file,  
not the matching string itself.

Man grep's "The scanning will stop on the first match" refers to  
scanning inside a certain file; so once a decision has been reached as  
to whether it satifies the condition or not, then grep will move on to  
testing the next file.

-- 
John

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

#201529

On Mon 22 Oct 2018 at 10:12:57 (+0900), John Crawley wrote:
> On 21/10/2018 22.48, David Wright wrote:
> > On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
> > > On 10/20/2018 08:16 PM, John Crawley wrote:
> > > > On 20/10/2018 19.28, Richard Owlett wrote:
> > > > > ...I would have expected to use an explicit pipe command
> > > > > between 'find' and 'grep'.
> > > > 
> > > > In fact, depending on the exact conditions of your search, you
> > > > might not need to use find at all. 'grep -r' will do a recursive
> > > > search, starting at whatever directory you give it, looking inside
> > > > every file for some content. Like:
> > > > 
> > > > grep -r 'keyword_or_regex' dirname
> > > > 
> > > > Of course, 'man grep' for various options...
> > > > 
> > > 
> > > I wish a list of files with a specific extension in a directory which
> > > contain keywordA but not keywordB. Recursing down the directory tree
> > > was the primary objection to the MATE search tool.
> > 
> > At last, a direct question!
> > 
> > $ grep -L keywordB $(grep -l keywordA a-directory/*extension)
> > 
> > Mix with quotes according to taste and needs.
> 
> I'm pretty sure David's code above will do exactly what the OP asked for.
> 
> This is about searching through a list of files, so I think the
> subsequent discussion of stdin might have been a bit confusing, since
> it's only one file.

I was only trying to demonstrate the side-effect of stopping on stdin,
not the continuation of scanning other files, which I had already
pointed out.

> The -L and -l options are about what grep outputs: the name of a file,
> not the matching string itself.
> 
> Man grep's "The scanning will stop on the first match" refers to
> scanning inside a certain file; so once a decision has been reached as
> to whether it satifies the condition or not, then grep will move on to
> testing the next file.

Yes, continuing to test further files is implied by the plural "files"
in the options' names. Stopping after the first match gives an obvious
efficiency gain which need not necessarily have been documented¹.

In the case of stdin, however, stopping after a match has an important
side effect that does mean it *needs* to be documented. Omitting it
would be a bug.

Perhaps it was unwise, though, to suggest a practical demonstration
using stdin. I hadn't realised how little the questioner understood
about using stdin in that manner.

¹ For example, does grep need to open a file whose length is shorter
than the string being sought? Does it need to document whether it
skips opening it? Will a user complain because the file's last-access
time is not updated if grep doesn't open it? Perhaps not. (Of course,
stdin would not be affected in this particular case as its length is
undefined.)

Cheers,
David.

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

#201527

On Sun, Oct 21, 2018 at 08:48:28AM -0500, David Wright wrote:
> On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
> > I wish a list of files with a specific extension in a directory which
> > contain keywordA but not keywordB. Recursing down the directory tree
> > was the primary objection to the MATE search tool.
> 
> At last, a direct question!
> 
> $ grep -L keywordB $(grep -l keywordA a-directory/*extension)
> 
> Mix with quotes according to taste and needs.

That doesn't recurse (it only considers files at depth 1 in a single
subdirectory), and it falls apart on filenames with whitespace.

If we ignore the recursion part for a moment, I have a FAQ for the
"match A but not B" part:

https://mywiki.wooledge.org/BashFAQ/079

The specific example for this case (foo but NOT bar) is at the bottom:

awk '/foo/{good=1} /bar/{good=0;exit} END{exit !good}'

So, all we have to do is write the recursion and extension-filtering
parts and link them together with the awk command.  This is fairly
straightforward with the standard tools.

find . -type f -name '*.myext' -exec \
  awk '/keywordA/{good=1} /keywordB/{good=0;exit} END{exit !good}' {} \; -print


Testing:

wooledg:~$ mkdir /tmp/x && cd "$_"
wooledg:/tmp/x$ mkdir -p a/b/c a/b/d
wooledg:/tmp/x$ echo keywordA > a/b/c/good.myext
wooledg:/tmp/x$ echo keywordA keywordB > a/b/d/bad.myext
wooledg:/tmp/x$ find . -type f -name '*.myext' -exec \
>   awk '/keywordA/{good=1} /keywordB/{good=0;exit} END{exit !good}' {} \; -print
./a/b/c/good.myext


Now, the obvious unstated part of the question is that he will want
keywordA and keywordB to be passed as parameters (although knowing him,
he will require 17 messages to tell us this).

This is where it actually gets "hard", because the obvious thing to do
would be to change the quotes on the awk command and embed $1 and $2 in
it directly.  That is a TRAP.  It's a code injection bug, because the
parameters given by the user could contain code that is meaningful to awk,
which would lead to unexpected results.

For that part of the program, I refer you to:

https://mywiki.wooledge.org/BashProgramming/05

I would use the "awk variables" approach for this one:

#!/bin/sh
if test "$#" != 2; then
  printf "usage: %s goodpat badpat\n" "$0" >&2
  exit 1
fi

find . -type f -name '*.myext' -exec \
  awk -v goodpat="$1" -v badpat="$2" \
    '$0 ~ goodpat {good=1} $0 ~ badpat {good=0;exit} END{exit !good}' {} \; \
  -print


And, testing:

wooledg:/tmp/x$ set -- wordA wordB
wooledg:/tmp/x$ find . -type f -name '*.myext' -exec \
>   awk -v goodpat="$1" -v badpat="$2" \
>     '$0 ~ goodpat {good=1} $0 ~ badpat {good=0;exit} END{exit !good}' {} \; \
>   -print
./a/b/c/good.myext


And then, the obvious next extension after THAT would be to make the
filename extension a parameter.  The shell part of that one is super
easy (no code injection problems with find -name), so I won't bother
showing it.

At that point, the user interface becomes the real issue.  Do you
put the extension argument first, or last?  Do you make it an option?
Do you hardcode a default extension, or does the lack of a specified
extension mean that you drop the -name filter altogether?  Or do you
give up the command line interface entirely, and go with a Tk dialog?

But he'll never, ever, EVER be able to answer those questions, so we
won't have to worry about it.

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

#201528

On Mon 22 Oct 2018 at 09:09:12 (-0400), Greg Wooledge wrote:
> On Sun, Oct 21, 2018 at 08:48:28AM -0500, David Wright wrote:
> > On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
> > > I wish a list of files with a specific extension in a directory which
> > > contain keywordA but not keywordB. Recursing down the directory tree
> > > was the primary objection to the MATE search tool.
                      ↑↑↑↑↑↑↑↑↑
> > 
> > At last, a direct question!
> > 
> > $ grep -L keywordB $(grep -l keywordA a-directory/*extension)
> > 
> > Mix with quotes according to taste and needs.
> 
> That doesn't recurse (it only considers files at depth 1 in a single
> subdirectory),

Specifically required by the OP.

> and it falls apart on filenames with whitespace.

Left as an exercise for the reader.

> If we ignore the recursion part for a moment, I have a FAQ for the
> "match A but not B" part:
> 
> https://mywiki.wooledge.org/BashFAQ/079
> 
> The specific example for this case (foo but NOT bar) is at the bottom:
> 
> awk '/foo/{good=1} /bar/{good=0;exit} END{exit !good}'
> 
> So, all we have to do is write the recursion and extension-filtering
> parts and link them together with the awk command.  This is fairly
> straightforward with the standard tools.
> 
> find . -type f -name '*.myext' -exec \
>   awk '/keywordA/{good=1} /keywordB/{good=0;exit} END{exit !good}' {} \; -print
> 
> 
> Testing:
> 
> wooledg:~$ mkdir /tmp/x && cd "$_"
> wooledg:/tmp/x$ mkdir -p a/b/c a/b/d
> wooledg:/tmp/x$ echo keywordA > a/b/c/good.myext
> wooledg:/tmp/x$ echo keywordA keywordB > a/b/d/bad.myext
> wooledg:/tmp/x$ find . -type f -name '*.myext' -exec \
> >   awk '/keywordA/{good=1} /keywordB/{good=0;exit} END{exit !good}' {} \; -print
> ./a/b/c/good.myext
> 
> 
> Now, the obvious unstated part of the question is that he will want
> keywordA and keywordB to be passed as parameters (although knowing him,
> he will require 17 messages to tell us this).
> 
> This is where it actually gets "hard", because the obvious thing to do
> would be to change the quotes on the awk command and embed $1 and $2 in
> it directly.  That is a TRAP.  It's a code injection bug, because the
> parameters given by the user could contain code that is meaningful to awk,
> which would lead to unexpected results.
> 
> For that part of the program, I refer you to:
> 
> https://mywiki.wooledge.org/BashProgramming/05
> 
> I would use the "awk variables" approach for this one:
> 
> #!/bin/sh
> if test "$#" != 2; then
>   printf "usage: %s goodpat badpat\n" "$0" >&2
>   exit 1
> fi
> 
> find . -type f -name '*.myext' -exec \
>   awk -v goodpat="$1" -v badpat="$2" \
>     '$0 ~ goodpat {good=1} $0 ~ badpat {good=0;exit} END{exit !good}' {} \; \
>   -print
> 
> 
> And, testing:
> 
> wooledg:/tmp/x$ set -- wordA wordB
> wooledg:/tmp/x$ find . -type f -name '*.myext' -exec \
> >   awk -v goodpat="$1" -v badpat="$2" \
> >     '$0 ~ goodpat {good=1} $0 ~ badpat {good=0;exit} END{exit !good}' {} \; \
> >   -print
> ./a/b/c/good.myext
> 
> 
> And then, the obvious next extension after THAT would be to make the
> filename extension a parameter.  The shell part of that one is super
> easy (no code injection problems with find -name), so I won't bother
> showing it.
> 
> At that point, the user interface becomes the real issue.  Do you
> put the extension argument first, or last?  Do you make it an option?
> Do you hardcode a default extension, or does the lack of a specified
> extension mean that you drop the -name filter altogether?  Or do you
> give up the command line interface entirely, and go with a Tk dialog?
> 
> But he'll never, ever, EVER be able to answer those questions, so we
> won't have to worry about it.

No, but we all learn something from these posts; at least, I do.

Cheers,
David.

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

#201530

On Mon, Oct 22, 2018 at 10:24:35AM -0500, David Wright wrote:
> > > On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
> > > > I wish a list of files with a specific extension in a directory which
> > > > contain keywordA but not keywordB. Recursing down the directory tree
> > > > was the primary objection to the MATE search tool.
>                       ↑↑↑↑↑↑↑↑↑

> Specifically required by the OP.

I found the wording ambiguous, but I'm also only seeing the text
second-hand, without the full context.  So, I'll take part of the blame
for this, but not all of it.

*Most* people who are searching for the files containing a specific
pattern starting in a specific directory *want* recursion.  So, asking
that the search NOT recurse needs to be spelled out in extremely
explicit language.

With any of the find solutions that have already been given, one may
add "-maxdepth 1" to stop the recursion.  That's a non-portable option,
but this is debian-user, so it's perfectly acceptable here.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web