Re: An appropriate directory search tool?
- Date: Sun, 21 Oct 2018 13:52:15 -0500
- From: David Wright <deblis@xxxxxxxxxxxxxxxxx>
- Subject: Re: An appropriate directory search tool?
On Sun 21 Oct 2018 at 13:11:16 (-0400), rhkramer@xxxxxxxxx wrote:
> On Sunday, October 21, 2018 12:35:04 PM David Wright wrote:
> > On Sun 21 Oct 2018 at 11:45:49 (-0400), rhkramer@xxxxxxxxx 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:
> rhk@s19:/rhk/ked1$ grep test - >| /tmp/a ; echo "and the output is" ; cat /tmp/a
> rhk@s19:/rhk/ked1$ less /tmp/a
^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
> and the output is
> (standard input)
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