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

#27248

On 2019-06-18, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

> On 6/17/19 1:56 PM, Aragorn wrote:
>
>> How many times have you not heard Bill Gates or Steve Ballmer say 
>> that GNU/Linux was insecure, unstable, and the operating system of 
>> choice of terrorists?  Did you believe THAT too?  And their "data" 
>> about how the TCO of Windows was lower than that of GNU/Linux?
>
> I can't think of a single time that I did hear them say that.  I tended 
> to ignore them.  I did hear tell of them saying that, but I dismissed it 
> as largely ignorance or propaganda.

For a while, "TCO" was Microsoft's big propaganda buzzword -
at least until their arguments were so thoroughly refuted.
I think they started that campaign shortly after Bill Gates
gave up on whining about how the Department of Justice was
"stifling their right to innovate" (i.e. interfering with
their supposed right to destroy the true innovators).

>> [*] They even had a genuine hate campaign going on against KDE for 
>> several years because KDE 1.x was built upon the then still not freely 
>> licensed QT libraries, but even though this was changed for QT2 and 
>> KDE2, RedHat continued to boycott and libel KDE for several more years 
>> — all throughout the lifetime of KDE2 and the early years of KDE3 
>> — which earned them the moniker HatRed.
>
> Shame on them.

HatRed... I'll have to remember that one (even though I'm not a KDE fan).

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

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

#27164

Richard Kettlewell <invalid@invalid.invalid> writes:

> 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.

I suppose you have a point.  Sometimes you can just combine modules
in a pipeline or script instead of adding an option as demonstrated with
that find/grep thingie.  But clearly BWK is also advocating for
new modules vs adding options as the above quote shows.

And he doesn't give us any clear reasoning for which path to take
and ignores human factors.

-- 
Dan Espen

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

#27155

On 13/06/2019 16:22, Dan Espen wrote:
> 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.
> 
Well the point is that programs with an infinite mnumvber of argument 
combinatins are an infinite number of programs

Which is quicker - read 100 pages on 'man' or just locate the program 
you actually want?




-- 
“It is dangerous to be right in matters on which the established 
authorities are wrong.”

― Voltaire, The Age of Louis XIV

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

#27156

On Thu, 13 Jun 2019 03:15:45 -0700, T 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

Another interesting feature about grep I learned only a few years ago is
that it can compare two files:

grep -v -f file1 file2

and outputs differences to stdout.
-- 
Andreas

My random thoughts and comments
https://news-commentaries.blogspot.com/

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

#27158

On 6/13/19 12:58 PM, Andreas Kohlbach wrote:
> Another interesting feature about grep I learned only a few years 
> ago is that it can compare two files:
> 
> grep -v -f file1 file2
> 
> and outputs differences to stdout.

That's an abuse / misuse of a feature.

-f is used to specify a file of strings to search for.

The fact that it's a file with all of it's individual likes as strings 
of text is a side effect.  A side effect that I would not count on.

Consider the two files:

-a---
aaa
bbb
ccc
-a---

-b---
aaa
aa
a
bbb
bb
b
ccc
cc
c
-b---

The following command will fail to output any differences between the files:

    grep -v -f b a

That's because file a does contain /a/ line that matches (contains) all 
of the lines in file b.

But that does not mean that the two files are the same.

diff on the other hand will tell you if the files are truly the same or not.



-- 
Grant. . . .
unix || die

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

#27159

On Thu, 13 Jun 2019 14:29:30 -0600, Grant Taylor wrote:
>
> On 6/13/19 12:58 PM, Andreas Kohlbach wrote:
>> Another interesting feature about grep I learned only a few years
>> ago is that it can compare two files:
>>
>> grep -v -f file1 file2
>>
>> and outputs differences to stdout.
>
> That's an abuse / misuse of a feature.
>
> -f is used to specify a file of strings to search for.
>
> The fact that it's a file with all of it's individual likes as strings
> of text is a side effect.  A side effect that I would not count on.
>
> Consider the two files:
>
> -a---
> aaa
> bbb
> ccc
> -a---
>
> -b---
> aaa
> aa
> a
> bbb
> bb
> b
> ccc
> cc
> c
> -b---
>
> The following command will fail to output any differences between the files:
>
>    grep -v -f b a
>
> That's because file a does contain /a/ line that matches (contains)
> all of the lines in file b.
>
> But that does not mean that the two files are the same.
>
> diff on the other hand will tell you if the files are truly the same or not.

Oh thanks. The guy in another news group, who let me know about this,
might not be aware of this.
-- 
Andreas

My random thoughts and comments
https://news-commentaries.blogspot.com/

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

#27173

In comp.os.linux.misc, 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

Alternative way:

    find /etc/dnf -type f -exec grep xclude {} +

Much more typing for that, but can be much faster if you use find to be
more selective about the files to search, eg, don't grep .ISO files
when searching your home directory.

The 'find' method works with non-Gnu products, too, like Solaris find/grep.

Another way, install ripgrep:

https://github.com/BurntSushi/ripgrep

Then:

    rg xclude /etc/dnf

Ripgrep tries to be smart about not grep'ing binaries, and knows to
ignore .git/ directories and uses .gitignore. Ripgrep is your friend
when trying to find stuff in someone else's source code tree.

Elijah
------
always needs a fallback to standard tools

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

#27178

On 15/06/2019 05.10, Eli the Bearded wrote:
> In comp.os.linux.misc, 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
> 
> Alternative way:
> 
>     find /etc/dnf -type f -exec grep xclude {} +

But this launches grep on each found file, thus it is slower that only
using grep.

> 
> Much more typing for that, but can be much faster if you use find to be
> more selective about the files to search, eg, don't grep .ISO files
> when searching your home directory.
> 
> The 'find' method works with non-Gnu products, too, like Solaris find/grep.
> 
> Another way, install ripgrep:
> 
> https://github.com/BurntSushi/ripgrep
> 
> Then:
> 
>     rg xclude /etc/dnf
> 
> Ripgrep tries to be smart about not grep'ing binaries, and knows to
> ignore .git/ directories and uses .gitignore. Ripgrep is your friend
> when trying to find stuff in someone else's source code tree.

Interesting :-)


-- 
Cheers, Carlos.

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

#27179

"Carlos E.R." <robin_listas@es.invalid> writes:
> On 15/06/2019 05.10, Eli the Bearded wrote:
>> In comp.os.linux.misc, 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
>> 
>> Alternative way:
>> 
>>     find /etc/dnf -type f -exec grep xclude {} +
>
> But this launches grep on each found file, thus it is slower that only
> using grep.

No it doesn’t, it runs one instance of grep for many filenames.

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

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

#27180

In article <87pnnfvyaw.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell  <invalid@invalid.invalid> wrote:
>"Carlos E.R." <robin_listas@es.invalid> writes:
>> On 15/06/2019 05.10, Eli the Bearded wrote:
>>> In comp.os.linux.misc, 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
>>> 
>>> Alternative way:
>>> 
>>>     find /etc/dnf -type f -exec grep xclude {} +
>>
>> But this launches grep on each found file, thus it is slower that only
>> using grep.
>
>No it doesn't; it runs one instance of grep for many filenames.

That's because of the + symbol at the end of the line, which is an
extension that does kinda the same thing as the normal way of using xargs.

The more normal way to do this sort of thing is to pipe the output of find
into xargs.

BTW, what's really wrong with the "tip" which originated this thread is
that the following doesn't do what you expect:

    $ grep -r somestring *.c

Yes, I understand why it does what it does and, of course, it is not a bug,
but it is nevertheless not what you had hoped for when you typed it in.

I got bit by this a few days ago (before this thread got started).  Obvious
fix is to switch to the usual "find ...  | xargs grep" idiom.

-- 
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy  of the church so decides." 

    - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

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

#27182

On 6/15/19 7:16 AM, Kenny McCormack wrote:
> BTW, what's really wrong with the "tip" which originated this thread 
> is that the following doesn't do what you expect:

Please elaborate on what you mean.

Please include what "do what you expect" along with what it actually does.

> Yes, I understand why it does what it does and, of course, it is not 
> a bug, but it is nevertheless not what you had hoped for when you 
> typed it in.

I think that's highly dependent on what the to things are above.

> I got bit by this a few days ago (before this thread got started). 
> Obvious fix is to switch to the usual "find ...  | xargs grep" idiom.

What does "find ... | xargs grep" do differently?

I could speculate on a lot of this, but I'd rather ask and understand 
what you're thinking.



-- 
Grant. . . .
unix || die

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

#27184

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 6/15/19 7:16 AM, Kenny McCormack wrote:
>> I got bit by this a few days ago (before this thread got
>> started). Obvious fix is to switch to the usual "find ...  | xargs
>> grep" idiom.
>
> What does "find ... | xargs grep" do differently?

It fails to handle certain filenames.

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

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

#27183

In comp.os.linux.misc, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> Richard Kettlewell  <invalid@invalid.invalid> wrote:
[I wrote upthread:]
>>>> Alternative way:
>>>> 
>>>>     find /etc/dnf -type f -exec grep xclude {} +

>> No it doesn't; it runs one instance of grep for many filenames.
> That's because of the + symbol at the end of the line, which is an
> extension that does kinda the same thing as the normal way of using xargs.

You say "extension", I say "native feature". I've used that with
versions of find not from Gnu.

> The more normal way to do this sort of thing is to pipe the output of find
> into xargs.

That breaks on, say, Solaris with filenames that include whitespace,
whereas the find I suggested just works. Solaris's find does "-exec ...  +"
but doesn't do "-print0" (to use with "| xargs -0").

> BTW, what's really wrong with the "tip" which originated this thread is
> that the following doesn't do what you expect:
> 
>     $ grep -r somestring *.c

That depends on what you expect a fileglob to do. It works if you have a
bunch of directories named (eg) foo.c, bar.c, etc.

> Yes, I understand why it does what it does and, of course, it is not a bug,
> but it is nevertheless not what you had hoped for when you typed it in.

For me, understanding that fileglobs happen in the shell, before the
command is started, that the "*" must match something that does not
begin with a dot (at least for leading *) and is in the current directory, 
came to me a very long time ago and is well in-grained in my expectation
of how things work.

> I got bit by this a few days ago (before this thread got started).  Obvious
> fix is to switch to the usual "find ...  | xargs grep" idiom.

Also in-grained in me is a knowledge that filename suffixes are
convention, not rules, in Unix land. 

    $ rm -f count
    $ mv count.c count.gif
    $ gcc -o count -x c count.gif
    $ file count.gif count
    count.gif: C source, ASCII text
    count:     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.6.32, BuildID[sha1]=eb042230e49538d90790c25b0a9a3d2c42fedb3d, not stripped
    $

Elijah
------
the ".c" bit is very handy for ".c.o:" rules in a Makefile

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

#27200

On 6/14/19 8:10 PM, Eli the Bearded wrote:
> In comp.os.linux.misc, 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
> 
> Alternative way:
> 
>      find /etc/dnf -type f -exec grep xclude {} +

I always forget the `-type f ` and have to suffer the "not
a directory" whining

[toc] | [prev] | [standalone]

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

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

csiph-web