Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #27177
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Newsgroups | comp.os.linux.misc |
| Subject | Re: tip: sweet grep recurse feature |
| Date | 2019-06-15 13:42 +0200 |
| Message-ID | <272ftf-ur.ln1@Telcontar.valinor> (permalink) |
| References | (3 earlier) <87o931xxbz.fsf@LkoBDZeT.terraraq.uk> <qdu8ne$7b7$1@dont-email.me> <87d0jgy2jw.fsf@LkoBDZeT.terraraq.uk> <i7ydnTm4JMnJ9p7AnZ2dnUU78S_NnZ2d@brightview.co.uk> <qe029s$e2u$1@dont-email.me> |
On 14/06/2019 14.01, Dan Espen wrote: > Javier <invalid@invalid.invalid> writes: > >> 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 > > Sure looks to me like the perfect proof that adding -r to grep is the > right choice. > >> 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 > > rsync still doesn't have enough options. > It needs more options when it can't do it's job with existing options. > > I use rsync for backup of $HOME. > When I delete a file in $HOME, I want it deleted from the backup. > But suppose I deleted the file by accident. I want rsync to wait > a while before it deletes the backup, in my case I want to wait 30 > days so I can discover whether I deleted something I need. > > So, I recently solved this problem by running rsync a second time > as a dry-run with the delete option. Then I make a pass through all > the file names returned from this second pass looking at time stamps > and deleting files when they are 30 days old. This works but would > be so much cleaner if I could just code: > > --delete 30 > > on the first pass. > > Size of the module and smallness of the man page are irrelevant when > you can't do the job. Interesting. There is another way. You do a "new" backup with hardlinks to older backups. The backup for today does not have copies of files that were deleted, but the backup for "yesterday" has it. And unchanged files are not copied again, wasting space, but are links to the first appeareance on the backup. The other step needed is to purge backups older than 30 days. What I miss is storing the files compressed. -- Cheers, Carlos.
Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web