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

Groups > comp.os.linux.misc > #27148 > unrolled thread

tip: sweet grep recurse feature

Back to article view | Back to comp.os.linux.misc

Contents

  tip: sweet grep recurse feature T <T@invalid.invalid> - 2019-06-13 03:15 -0700
    Re: tip: sweet grep recurse feature Javier <invalid@invalid.invalid> - 2019-06-13 08:46 -0500
      Re: tip: sweet grep recurse feature Jean-David Beyer <jeandavid8@verizon.net> - 2019-06-13 09:51 -0400
        Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-13 09:17 -0600
      Re: tip: sweet grep recurse feature Dan Espen <dan1espen@gmail.com> - 2019-06-13 11:22 -0400
        Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-13 09:56 -0600
        Re: tip: sweet grep recurse feature Richard Kettlewell <invalid@invalid.invalid> - 2019-06-13 17:29 +0100
          Re: tip: sweet grep recurse feature Dan Espen <dan1espen@gmail.com> - 2019-06-13 15:38 -0400
            Re: tip: sweet grep recurse feature Richard Kettlewell <invalid@invalid.invalid> - 2019-06-14 09:49 +0100
              Re: tip: sweet grep recurse feature Javier <invalid@invalid.invalid> - 2019-06-14 04:39 -0500
                Re: tip: sweet grep recurse feature "Carlos E.R." <robin_listas@es.invalid> - 2019-06-14 12:11 +0200
                  Re: tip: sweet grep recurse feature Javier <invalid@invalid.invalid> - 2019-06-14 07:11 -0500
                    Re: tip: sweet grep recurse feature Jean-David Beyer <jeandavid8@verizon.net> - 2019-06-14 09:07 -0400
                    Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-14 12:44 -0600
                      Re: tip: sweet grep recurse feature Robert Heller <heller@deepsoft.com> - 2019-06-14 14:20 -0500
                        Re: tip: sweet grep recurse feature Eli the Bearded <*@eli.users.panix.com> - 2019-06-15 03:18 +0000
                          Re: tip: sweet grep recurse feature Robert Heller <heller@deepsoft.com> - 2019-06-14 23:05 -0500
                          Re: tip: sweet grep recurse feature Anssi Saari <as@sci.fi> - 2019-06-17 09:44 +0300
                            Re: tip: sweet grep recurse feature Fenris <fenris@invalid.invalid> - 2019-06-17 10:21 +0200
                  Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-14 12:50 -0600
                    Re: tip: sweet grep recurse feature "Carlos E.R." <robin_listas@es.invalid> - 2019-06-15 13:37 +0200
                Re: tip: sweet grep recurse feature Dan Espen <dan1espen@gmail.com> - 2019-06-14 08:01 -0400
                  Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-14 12:55 -0600
                    Re: tip: sweet grep recurse feature Dan Espen <dan1espen@gmail.com> - 2019-06-14 17:54 -0400
                      Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-14 20:20 -0600
                  Re: tip: sweet grep recurse feature "Carlos E.R." <robin_listas@es.invalid> - 2019-06-15 13:42 +0200
                    Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-15 11:09 -0600
                      Re: tip: sweet grep recurse feature "Carlos E.R." <robin_listas@es.invalid> - 2019-06-17 12:37 +0200
                        Re: tip: sweet grep recurse feature Aragorn <thorongil@telenet.be> - 2019-06-17 12:51 +0200
                          Re: tip: sweet grep recurse feature "Carlos E.R." <robin_listas@es.invalid> - 2019-06-17 12:57 +0200
                            Re: tip: sweet grep recurse feature Aragorn <thorongil@telenet.be> - 2019-06-17 14:20 +0200
                            Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-17 08:51 -0600
                              Re: tip: sweet grep recurse feature Aragorn <thorongil@telenet.be> - 2019-06-17 19:43 +0200
                                Re: tip: sweet grep recurse feature "Carlos E.R." <robin_listas@es.invalid> - 2019-06-17 20:38 +0200
                                Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-17 13:07 -0600
                                  Re: tip: sweet grep recurse feature Aragorn <thorongil@telenet.be> - 2019-06-17 21:56 +0200
                                    Re: tip: sweet grep recurse feature Georges <georges@prout.com> - 2019-06-17 22:30 +0200
                                    Re: tip: sweet grep recurse feature "Carlos E.R." <robin_listas@es.invalid> - 2019-06-17 22:19 +0200
                                    Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-17 19:43 -0600
                                      Re: tip: sweet grep recurse feature Aragorn <thorongil@telenet.be> - 2019-06-18 10:26 +0200
                                      Re: tip: sweet grep recurse feature Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2019-06-18 23:58 +0000
              Re: tip: sweet grep recurse feature Dan Espen <dan1espen@gmail.com> - 2019-06-14 08:07 -0400
        Re: tip: sweet grep recurse feature The Natural Philosopher <tnp@invalid.invalid> - 2019-06-13 19:42 +0100
    Re: tip: sweet grep recurse feature Andreas Kohlbach <ank@spamfence.net> - 2019-06-13 14:58 -0400
      Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-13 14:29 -0600
        Re: tip: sweet grep recurse feature Andreas Kohlbach <ank@spamfence.net> - 2019-06-13 16:38 -0400
    Re: tip: sweet grep recurse feature Eli the Bearded <*@eli.users.panix.com> - 2019-06-15 03:10 +0000
      Re: tip: sweet grep recurse feature "Carlos E.R." <robin_listas@es.invalid> - 2019-06-15 13:46 +0200
        Re: tip: sweet grep recurse feature Richard Kettlewell <invalid@invalid.invalid> - 2019-06-15 13:16 +0100
          Re: tip: sweet grep recurse feature gazelle@shell.xmission.com (Kenny McCormack) - 2019-06-15 13:16 +0000
            Re: tip: sweet grep recurse feature Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-15 11:12 -0600
              Re: tip: sweet grep recurse feature Richard Kettlewell <invalid@invalid.invalid> - 2019-06-15 22:26 +0100
            Re: tip: sweet grep recurse feature Eli the Bearded <*@eli.users.panix.com> - 2019-06-15 20:09 +0000
      Re: tip: sweet grep recurse feature T <T@invalid.invalid> - 2019-06-16 14:29 -0700

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

#27148 — tip: sweet grep recurse feature

that I did not know existed, until a friend on the Fedora group
show it to me:

You do a recurse through a directory looking for a pattern

$ grep -r 'xclude' /etc/dnf/
/etc/dnf/dnf.conf:excludepkgs=xrdp xorgxrdp

[toc] | [next] | [standalone]

#27149

T <T@invalid.invalid> wrote:
> that I did not know existed, until a friend on the Fedora group
> show it to me:
> 
> You do a recurse through a directory looking for a pattern
> 
> $ grep -r 'xclude' /etc/dnf/
> /etc/dnf/dnf.conf:excludepkgs=xrdp xorgxrdp

Brian W. Kernighan does not agree.

http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

Programs should have as as few options as possible.  Do one thing and
do it well.  For recursing through dirs you already have find(1).

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

#27150

On 6/13/19 9:46 AM, Javier wrote:
> T <T@invalid.invalid> wrote:
>> that I did not know existed, until a friend on the Fedora group
>> show it to me:
>>
>> You do a recurse through a directory looking for a pattern
>>
>> $ grep -r 'xclude' /etc/dnf/
>> /etc/dnf/dnf.conf:excludepkgs=xrdp xorgxrdp
> 
> Brian W. Kernighan does not agree.
> 
> http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
> 
> Programs should have as as few options as possible.  Do one thing and
> do it well.  For recursing through dirs you already have find(1).
> 

Sometimes _locate_ piped into _grep_ will do it faster.

-- 
  .~.  Jean-David Beyer
  /V\  PGP-Key:166D840A 0C610C8B
 /( )\ Shrewsbury, New Jersey
 ^^-^^ 09:50:01 up 4 days, 16:32, 2 users, load average: 4.48, 4.54, 4.51

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

#27151

On 6/13/19 7:51 AM, Jean-David Beyer wrote:
> Sometimes _locate_ piped into _grep_ will do it faster.

(recursive) grep will search through file contents.

Both locate and find will search the file name.

File name and file contents are distinctly two different sets of data 
and may very well be unrelated to each other.



-- 
Grant. . . .
unix || die

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

#27152

Javier <invalid@invalid.invalid> writes:

> T <T@invalid.invalid> wrote:
>> that I did not know existed, until a friend on the Fedora group
>> show it to me:
>> 
>> You do a recurse through a directory looking for a pattern
>> 
>> $ grep -r 'xclude' /etc/dnf/
>> /etc/dnf/dnf.conf:excludepkgs=xrdp xorgxrdp
>
> Brian W. Kernighan does not agree.
>
> http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
>
> Programs should have as as few options as possible.  Do one thing and
> do it well.  For recursing through dirs you already have find(1).

I thought we'd already discovered that BWK was wrong.
Perhaps he can explain how having 2 grep programs,
perhaps "grep" and "grepr" (for grep recursive) is superior
to "grep -r".  If he can manage that, perhaps he can read
a modern grep man page and tell us how many variations on
grep we'd need to accomplish everything modern grep does.

We'd need thousands of grep programs to accomplish all
the permutations.  Good luck with that.

-- 
Dan Espen

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

#27153

On 6/13/19 9:22 AM, Dan Espen wrote:
> I thought we'd already discovered that BWK was wrong.

I think the spirit / intent of his statement is good.

At least in so far as I don't think an editor should be an email client 
or a web browser.

grep is broadly meant for searching for something inside of file(s).  So 
if there is a feature that is one (or maybe two) degrees removed from 
that core function, then perhaps it is within scope.

Searching through multiple files and doing so recursively seem to be 
directly related to searching in a file.  Likewise with zgrep for 
compressed files.

I'm sure that it's possible to hack together a command / small script 
that can do what's being suggested.  With this construct in mind, I'm 
likely not going to complain about something that's directly on the 
other side of a pipe next to grep.

Just my 2¢ worth.



-- 
Grant. . . .
unix || die

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

#27154

Dan Espen <dan1espen@gmail.com> writes:
> Javier <invalid@invalid.invalid> writes:
>> T <T@invalid.invalid> wrote:
>>> that I did not know existed, until a friend on the Fedora group
>>> show it to me:
>>> 
>>> You do a recurse through a directory looking for a pattern
>>> 
>>> $ grep -r 'xclude' /etc/dnf/
>>> /etc/dnf/dnf.conf:excludepkgs=xrdp xorgxrdp
>>
>> Brian W. Kernighan does not agree.
>>
>> http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
>>
>> Programs should have as as few options as possible.  Do one thing and
>> do it well.  For recursing through dirs you already have find(1).
>
> I thought we'd already discovered that BWK was wrong.
> Perhaps he can explain how having 2 grep programs,
> perhaps "grep" and "grepr" (for grep recursive) is superior
> to "grep -r".

I don’t think you can have read the paper, since he doesn’t argue that
there should be a separate program for each use case.

-- 
https://www.greenend.org.uk/rjk/

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

#27157

Richard Kettlewell <invalid@invalid.invalid> writes:

> Dan Espen <dan1espen@gmail.com> writes:
>> Javier <invalid@invalid.invalid> writes:
>>> T <T@invalid.invalid> wrote:
>>>> that I did not know existed, until a friend on the Fedora group
>>>> show it to me:
>>>> 
>>>> You do a recurse through a directory looking for a pattern
>>>> 
>>>> $ grep -r 'xclude' /etc/dnf/
>>>> /etc/dnf/dnf.conf:excludepkgs=xrdp xorgxrdp
>>>
>>> Brian W. Kernighan does not agree.
>>>
>>> http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
>>>
>>> Programs should have as as few options as possible.  Do one thing and
>>> do it well.  For recursing through dirs you already have find(1).
>>
>> I thought we'd already discovered that BWK was wrong.
>> Perhaps he can explain how having 2 grep programs,
>> perhaps "grep" and "grepr" (for grep recursive) is superior
>> to "grep -r".
>
> I don’t think you can have read the paper, since he doesn’t argue that
> there should be a separate program for each use case.

I read the paper.
At least last time this came up.
Okay, just scanned the thing again.

Basically the whole paper is an admonishment about keeping programs
simple,  mainly by not adding options.

When it finally gets down to it, he concedes that sometimes you add
options:

  Separate programs  are not  always better than  wider options;  which is
  better depends  on the problem.  Whenever  one needs a way  to perform a
  new function,  one faces the  choice of whether to  add a new  option or
  write a new program...The guiding principle for making the choice should
  be that each  program does one thing. Options are  appropriately added
  to a  program that already has  the right functionality. If  there is no
  such program, then a new program is called for.

So, he's  really giving us only  the vaguest idea when  we add options
and  when we  write new  programs.  We  find out,  it "depends",  but we
should "do one thing", and you can add options when the program
"already has the right functionality".

I find the "do one thing" rule impossible to interpret.
How can any program do one thing if it has options?

BWK addresses program elegance and never mentions user expectations.

-- 
Dan Espen

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

#27160

Dan Espen <dan1espen@gmail.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Dan Espen <dan1espen@gmail.com> writes:
>>> Javier <invalid@invalid.invalid> writes:
>>>> Brian W. Kernighan does not agree.
>>>>
>>>> http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
>>>>
>>>> Programs should have as as few options as possible.  Do one thing and
>>>> do it well.  For recursing through dirs you already have find(1).
>>>
>>> I thought we'd already discovered that BWK was wrong.
>>> Perhaps he can explain how having 2 grep programs,
>>> perhaps "grep" and "grepr" (for grep recursive) is superior
>>> to "grep -r".
>>
>> I don’t think you can have read the paper, since he doesn’t argue that
>> there should be a separate program for each use case.
>
> I read the paper.
> At least last time this came up.
> Okay, just scanned the thing again.
>
> Basically the whole paper is an admonishment about keeping programs
> simple,  mainly by not adding options.
>
> When it finally gets down to it, he concedes that sometimes you add
> options:
>
>   Separate programs  are not  always better than  wider options;  which is
>   better depends  on the problem.  Whenever  one needs a way  to perform a
>   new function,  one faces the  choice of whether to  add a new  option or
>   write a new program...The guiding principle for making the choice should
>   be that each  program does one thing. Options are  appropriately added
>   to a  program that already has  the right functionality. If  there is no
>   such program, then a new program is called for.
>
> So, he's  really giving us only  the vaguest idea when  we add options
> and  when we  write new  programs.  We  find out,  it "depends",  but we
> should "do one thing", and you can add options when the program
> "already has the right functionality".
>
> I find the "do one thing" rule impossible to interpret.
> How can any program do one thing if it has options?
>
> BWK addresses program elegance and never mentions user expectations.

By focussing narrowly on options you appear to have completely missed
the thrust of the argument, which is (the claim that) loosely coupled
composition of logically separate functionality is a better design than
combining multiple unrelated functionalities into single programs.
Whether it’s true is contextual, but arguments about ‘grepr’ don’t
address it.

-- 
https://www.greenend.org.uk/rjk/

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

#27161

Richard Kettlewell <invalid@invalid.invalid> wrote:
> Dan Espen <dan1espen@gmail.com> writes:
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>> Dan Espen <dan1espen@gmail.com> writes:
>>>> Javier <invalid@invalid.invalid> writes:
>>>>> Brian W. Kernighan does not agree.
>>>>>
>>>>> http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
>>>>>
>>>>> Programs should have as as few options as possible.  Do one thing and
>>>>> do it well.  For recursing through dirs you already have find(1).
>>>>
>>>> I thought we'd already discovered that BWK was wrong.
>>>> Perhaps he can explain how having 2 grep programs,
>>>> perhaps "grep" and "grepr" (for grep recursive) is superior
>>>> to "grep -r".
>>>
>>> I don’t think you can have read the paper, since he doesn’t argue that
>>> there should be a separate program for each use case.
>>
>> I read the paper.
>> At least last time this came up.
>> Okay, just scanned the thing again.
>>
>> Basically the whole paper is an admonishment about keeping programs
>> simple,  mainly by not adding options.
>>
>> When it finally gets down to it, he concedes that sometimes you add
>> options:
>>
>>   Separate programs  are not  always better than  wider options;  which is
>>   better depends  on the problem.  Whenever  one needs a way  to perform a
>>   new function,  one faces the  choice of whether to  add a new  option or
>>   write a new program...The guiding principle for making the choice should
>>   be that each  program does one thing. Options are  appropriately added
>>   to a  program that already has  the right functionality. If  there is no
>>   such program, then a new program is called for.
>>
>> So, he's  really giving us only  the vaguest idea when  we add options
>> and  when we  write new  programs.  We  find out,  it "depends",  but we
>> should "do one thing", and you can add options when the program
>> "already has the right functionality".
>>
>> I find the "do one thing" rule impossible to interpret.
>> How can any program do one thing if it has options?
>>
>> BWK addresses program elegance and never mentions user expectations.
> 
> By focussing narrowly on options you appear to have completely missed
> the thrust of the argument, which is (the claim that) loosely coupled
> composition of logically separate functionality is a better design than
> combining multiple unrelated functionalities into single programs.

Exactly, that is what BWK advocates.  Coupling simple tools through pipes.
For the usage case of the OP:

    find /etc/dnf/ \! -type d | xargs grep xclude

By adding less options the program source code is simpler and its
manpage thinner.  Otherwise you end up with behemoths like rsync.
Look at its manpage:

$ man rsync | wc -l
3870

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

#27162

On 14/06/2019 11.39, Javier wrote:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Dan Espen <dan1espen@gmail.com> writes:
>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>>> Dan Espen <dan1espen@gmail.com> writes:
>>>>> Javier <invalid@invalid.invalid> writes:
>>>>>> Brian W. Kernighan does not agree.
>>>>>>
>>>>>> http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
>>>>>>
>>>>>> Programs should have as as few options as possible.  Do one thing and
>>>>>> do it well.  For recursing through dirs you already have find(1).
>>>>>
>>>>> I thought we'd already discovered that BWK was wrong.
>>>>> Perhaps he can explain how having 2 grep programs,
>>>>> perhaps "grep" and "grepr" (for grep recursive) is superior
>>>>> to "grep -r".
>>>>
>>>> I don’t think you can have read the paper, since he doesn’t argue that
>>>> there should be a separate program for each use case.
>>>
>>> I read the paper.
>>> At least last time this came up.
>>> Okay, just scanned the thing again.
>>>
>>> Basically the whole paper is an admonishment about keeping programs
>>> simple,  mainly by not adding options.
>>>
>>> When it finally gets down to it, he concedes that sometimes you add
>>> options:
>>>
>>>   Separate programs  are not  always better than  wider options;  which is
>>>   better depends  on the problem.  Whenever  one needs a way  to perform a
>>>   new function,  one faces the  choice of whether to  add a new  option or
>>>   write a new program...The guiding principle for making the choice should
>>>   be that each  program does one thing. Options are  appropriately added
>>>   to a  program that already has  the right functionality. If  there is no
>>>   such program, then a new program is called for.
>>>
>>> So, he's  really giving us only  the vaguest idea when  we add options
>>> and  when we  write new  programs.  We  find out,  it "depends",  but we
>>> should "do one thing", and you can add options when the program
>>> "already has the right functionality".
>>>
>>> I find the "do one thing" rule impossible to interpret.
>>> How can any program do one thing if it has options?
>>>
>>> BWK addresses program elegance and never mentions user expectations.
>>
>> By focussing narrowly on options you appear to have completely missed
>> the thrust of the argument, which is (the claim that) loosely coupled
>> composition of logically separate functionality is a better design than
>> combining multiple unrelated functionalities into single programs.
> 
> Exactly, that is what BWK advocates.  Coupling simple tools through pipes.
> For the usage case of the OP:
> 
>     find /etc/dnf/ \! -type d | xargs grep xclude
> 
> By adding less options the program source code is simpler and its
> manpage thinner.  

Yes, but then the user has to handle more complex incantations, which
might perform slower as well.  I I have to learn that line above, I
would probably store it in my text file of recipes, or store the single
recursive grep with options instead, which is shorter.

Having small simple programs may not go that well with ease of use.


> Otherwise you end up with behemoths like rsync.
> Look at its manpage:
> 
> $ man rsync | wc -l
> 3870

Well, that is an extreme. But even so I still prefer that to having to
use a dozen rsync program variations like rsync1, rsync2, rsync3 or
whatever name. I never know what *grep variation to use for what.

-- 
Cheers, Carlos.

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

#27165

Carlos E.R. <robin_listas@es.invalid> wrote:
>> By adding less options the program source code is simpler and its
>> manpage thinner.  
> 
> Yes, but then the user has to handle more complex incantations, which
> might perform slower as well.  I I have to learn that line above, I
> would probably store it in my text file of recipes, or store the single
> recursive grep with options instead, which is shorter.
> 
> Having small simple programs may not go that well with ease of use.

It's much easier to learn a few options of find than to memorize the
different incompatible options of each tool.  An extreme example are
the file selection options of tar and rsync.  Both have dozens of
different options for file selection.  Knowing the 30 tar options for
file selection is useless when you use rsync.

>> $ man rsync | wc -l
>> 3870
> 
> Well, that is an extreme. But even so I still prefer that to having to
> use a dozen rsync program variations like rsync1, rsync2, rsync3 or
> whatever name. I never know what *grep variation to use for what.

You just need one rsync, and learn to use find.  See

lynx nntp://news.aioe.org/O9udnXO7--iqIlDBnZ2dnUU78UPNnZ2d@brightview.co.uk
lynx nntp://news.aioe.org/oJKdndBQ5PPMmVPBnZ2dnUU78N_NnZ2d@brightview.co.uk

or the same archived by gg:

https://groups.google.com/forum/message/raw?msg=comp.unix.programmer/8vs-P0nV5xU/9HeMtDouBQAJ
https://groups.google.com/forum/message/raw?msg=comp.unix.programmer/8vs-P0nV5xU/ETFQNFE-BQAJ

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

#27166

On 6/14/19 8:11 AM, Javier wrote:
> It's much easier to learn a few options of find than to memorize the
> different incompatible options of each tool.  An extreme example are
> the file selection options of tar and rsync.  Both have dozens of
> different options for file selection.  Knowing the 30 tar options for
> file selection is useless when you use rsync.

I remember a plotting subroutine, called tplot if I remember correctly,
that had about 34 arguments. The first two arguments were pointers to
the arrays containing the x and y values. It could do anything.

But people started writing simplified versions of it taking far fewer
arguments, and then calling tplot. There were so many that choosing
among them became too difficult, and I just learned to use tplot directly.

-- 
  .~.  Jean-David Beyer
  /V\  PGP-Key:166D840A 0C610C8B
 /( )\ Shrewsbury, New Jersey
 ^^-^^ 08:55:01 up 5 days, 15:37, 2 users, load average: 4.73, 5.31, 4.97

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

#27167

On 6/14/19 6:11 AM, Javier wrote:
> It's much easier to learn a few options of find than to memorize the 
> different incompatible options of each tool.

Don't memorize /all/ of the options.  /Remember/ but not necessarily 
/memorize/ the /few/ options that you need.  Where need is defined as 
you want to do something and that option is how you do it.

Be aware that the other options exist and know where you can find them 
if / when you need them in the future.



-- 
Grant. . . .
unix || die

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

#27170

At Fri, 14 Jun 2019 12:44:00 -0600 Grant Taylor <gtaylor@tnetconsulting.net> wrote:

> 
> On 6/14/19 6:11 AM, Javier wrote:
> > It's much easier to learn a few options of find than to memorize the 
> > different incompatible options of each tool.
> 
> Don't memorize /all/ of the options.  /Remember/ but not necessarily 
> /memorize/ the /few/ options that you need.  Where need is defined as 
> you want to do something and that option is how you do it.
> 
> Be aware that the other options exist and know where you can find them 
> if / when you need them in the future.

Right. The *most important tool* on your Linux box is the man command...

> 
> 
> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                         

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

#27174

In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
> Right. The *most important tool* on your Linux box is the man command...

SEE ALSO
      The full documentation for TOOL is maintained as a Texinfo manual.   If
      the  info  and  TOOL  programs are properly installed at your site, the
      command

	    info TOOL

      should give you access to the complete manual.


Elijah
------
fucking hates the info program

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

#27175

At Sat, 15 Jun 2019 03:18:26 +0000 (UTC) Eli the Bearded <*@eli.users.panix.com> wrote:

> 
> In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
> > Right. The *most important tool* on your Linux box is the man command...
> 
> SEE ALSO
>       The full documentation for TOOL is maintained as a Texinfo manual.   If
>       the  info  and  TOOL  programs are properly installed at your site, the
>       command
> 
> 	    info TOOL
> 
>       should give you access to the complete manual.
> 
> 
> Elijah
> ------
> fucking hates the info program

Fortunately most of the *important* commands have proper man pages.  And yes, 
info sucks big time.  Always a pain to look up something obscure relating to 
the auto<mumble> tools...

>                        

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                   

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

#27203

Eli the Bearded <*@eli.users.panix.com> writes:

> In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
>> Right. The *most important tool* on your Linux box is the man command...
>
> SEE ALSO
>       The full documentation for TOOL is maintained as a Texinfo manual.   If
>       the  info  and  TOOL  programs are properly installed at your site, the
>       command
>
> 	    info TOOL
>
>       should give you access to the complete manual.

Funny part is, sometimes info brings up the man page, word for
word. Including the note about using info for the "complete manual".

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

#27204

> Eli the Bearded <*@eli.users.panix.com> writes:
>> In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
>>> Right. The *most important tool* on your Linux box is the man command...
>>
>> SEE ALSO
>>       The full documentation for TOOL is maintained as a Texinfo manual.   If
>>       the  info  and  TOOL  programs are properly installed at your site, the
>>       command
>>
>> 	    info TOOL
>>
>>       should give you access to the complete manual.
>
> Funny part is, sometimes info brings up the man page, word for
> word. Including the note about using info for the "complete manual".

Yeah but it brings it up only if no info page is available, so quite 
reasonable.

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

#27168

On 6/14/19 4:11 AM, Carlos E.R. wrote:
> But even so I still prefer that to having to use a dozen rsync program 
> variations like rsync1, rsync2, rsync3 or whatever name.

I think there is something to be said for code reuse / overlap.

What percentage of a pair of programs that do similar but slightly 
different things can re-use the same code?  If the reuse / overlap is a 
large enough percentage, then chances are good that the variant could 
qualify as an option to one program.

> I never know what *grep variation to use for what.

I think of it this way (using aliases as a demonstration):

grep
alias egrep='grep -e'
alias fgrep='grep -f'

grep by itself is sort of a default and does a number of different things.

egrep is grep in a mode expecting / optimized for regular expressions.

fgrep is grep in a mode expecting fixed text patterns.

I use different greps depending on what I'm doing and looking for.

I usually use egrep / fgrep instead of the grep -e / grep -f variants 
because I try to minimize key presses.



-- 
Grant. . . .
unix || die

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

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

Back to top | Article view | comp.os.linux.misc

csiph-web