another excellent example why your posts are almost always worth reading.
thank you! :)
On Thu, Jan 19, 2023 at 02:00:00PM +0100, DdB wrote:
> Am 19.01.2023 um 13:13 schrieb Greg Wooledge:
> > The fact that this *appears* to work is what causes so much confusion.
> > It will "work" some of the time, but not all of the time, and you'll
> > get different results depending on which direc
On Thu, Jan 19, 2023 at 02:00:00PM +0100, DdB wrote:
[...]
> I was really curious, how Greg would put words to this one. And i gotta
> applaud: Such unambiguous explanations, and so circumspect at the same
> time. Even understanding the basis for confusion, i could learn
> something new from this
Am 19.01.2023 um 13:13 schrieb Greg Wooledge:
> The fact that this *appears* to work is what causes so much confusion.
> It will "work" some of the time, but not all of the time, and you'll
> get different results depending on which directory you're in, on which
> computer.
>
> Bash has two other
On Thu, Jan 19, 2023 at 07:13:46AM -0500, Greg Wooledge wrote:
[...]
> So, just to add to the list of people who've already said it: always
> quote the patterns that you pass to apt list, because you want apt
> to use them directly, without your shell interfering.
And, if in doubt, just replace
d globs. The first one
is called "nullglob", and if it's turned on, an unmatched glob is simply
discarded from the command argument list.
unicorn:~$ bash
unicorn:~$ shopt | grep glob
dotglob off
extglob off
failgloboff
globasciiranges on
globstaroff
noc
llo together,
> > > listing packages in apt with ”sudo“ in the title returns different output
> > > (bash commands at the end of the email). I would fill a bug report, but
> > > I'm not sure whether to address it to grep or apt. How do you see this?
> > >
ash commands at the end of the email). I would fill a bug report, but I'm
> > not sure whether to address it to grep or apt. How do you see this?
> >
> > Kind regards
> > Julian Schreck
> > --
> > $ apt list sudo* vs. $ apt list | grep "^sudo[a-z-]
Am Thu, Jan 19, 2023 at 09:10:30AM +0100 schrieb js-p...@online.de:
Hello Julian,
> Hello together,
> listing packages in apt with ”sudo“ in the title returns different output
> (bash commands at the end of the email). I would fill a bug report, but I'm
> not sure whether to a
19.01.23, 09:10 +0100, js-p...@online.de:
Hello together,
listing packages in apt with ”sudo“ in the title returns different output (bash
commands at the end of the email). I would fill a bug report, but I'm not sure
whether to address it to grep or apt. How do you see this?
To me it
Am 19.01.2023 um 09:10 schrieb js-p...@online.de:
> Hello together,
> listing packages in apt with ”sudo“ in the title returns different output
> (bash commands at the end of the email). I would fill a bug report, but I'm
> not sure whether to address it to grep or apt. Ho
Hello together,
listing packages in apt with ”sudo“ in the title returns different output (bash
commands at the end of the email). I would fill a bug report, but I'm not sure
whether to address it to grep or apt. How do you see this?
Kind regards
Julian Schreck
--
$ apt list sudo* vs.
On Wed, 21 Dec 2022 at 04:18, Lee wrote:
> On 12/20/22, David wrote:
> > $ echo -e '100:CD001\nXXX\n200:CD001' | awk 'BEGIN { FS=":" ; done=0 }
> > /CD001/ && done==0 { print $1 - 50 ; done=1 }'
> > 50
>
> You can do it without flags:
>
> $ echo -e '100:CD001\nXXX\n200:CD001' | awk -F: '/CD001/
On 12/20/22, David wrote:
> On Tue, 20 Dec 2022 at 22:04, David wrote:
>> On Tue, 20 Dec 2022 at 22:02, David wrote:
>
>> > $ echo -e '100:CD001\n200:CD001' | awk 'BEGIN { FS=":" } /CD001/ &&
>> > NR==1 { print $1 - 50 }'
>> > 50
>>
>> Oops, my mistake, that's not the solution. Give me another m
> Not that that is always important. But I just commented today
> because so often 'awk' is ignored as if its only capability is 'print $1'
> when in fact it is actually very powerful but neglected.
FWIW, `sed` can also do that job. Tho the subtraction part would take
a lot more work (`sed` does
On Tue, 20 Dec 2022 at 22:04, David wrote:
> On Tue, 20 Dec 2022 at 22:02, David wrote:
> > $ echo -e '100:CD001\n200:CD001' | awk 'BEGIN { FS=":" } /CD001/ &&
> > NR==1 { print $1 - 50 }'
> > 50
>
> Oops, my mistake, that's not the solution. Give me another minute and I
> will post a better one
Hi,
The Wanderer wrote:
> With the '-o' option, grep prints only the parts of the line that were
> matched - but the plural here is very relevant. If that guess is
> correct, then the "line" in question has *four* occurrences, so grep
> prints them all - each on
On Tue, 20 Dec 2022 at 22:02, David wrote:
> $ echo -e '100:CD001\n200:CD001' | awk 'BEGIN { FS=":" } /CD001/ &&
> NR==1 { print $1 - 50 }'
> 50
Oops, my mistake, that's not the solution. Give me another minute and I
will post a better one one.
On Tue, 20 Dec 2022 at 21:53, The Wanderer wrote:
> On 2022-12-20 at 05:37, David wrote:
> > On Tue, 20 Dec 2022 at 21:10, The Wanderer wrote:
> >> On 2022-12-20 at 02:51, Thomas Schmitt wrote:
> >>> This contradicts the promises of man grep about option -m.
>
On 2022-12-20 at 05:37, David wrote:
> On Tue, 20 Dec 2022 at 21:10, The Wanderer
> wrote:
>
>> On 2022-12-20 at 02:51, Thomas Schmitt wrote:
>>> This contradicts the promises of man grep about option -m.
>>
>> It does seem to, at least at a glance - bu
On Tue, 20 Dec 2022 at 21:10, The Wanderer wrote:
> On 2022-12-20 at 02:51, Thomas Schmitt wrote:
> >>> offst=$( expr \
> >>> $( grep -a -o -b -m 1 CD001 cdimage.iso \
> >>> | sed -e 's/:/ /' \
> >>>
On 2022-12-20 at 02:51, Thomas Schmitt wrote:
> Hi,
>
> i wrote:
>>> To obtain the offset of the first occurence of "CD001", do
>>>
>>> offst=$( expr \
>>> $( grep -a -o -b -m 1 CD001 cdimage.iso \
>>>
Le 11/30/22 à 4:02 PM, Yassine Chaouche a écrit :
But even then, translation files might contain more than one entry for same
package,
maybe one for each (version x architecture) product.
For eg.:
$ grep-dctrl winbind -s Description-en
/var/lib/apt/lists
2 at 17:25:45 (+0100), Yassine Chaouche wrote:
I tried to achieve the same w/o using apt-cache, but couldn't.
My failed attempts were :
1/
16:37:50 ~ -1- $ grep-dctrl -PX syslog-summary
/var/lib/apt/lists/*_Packages
Thos
Please don't post HTML, but text.
On Sun 27 Nov 2022 at 17:25:45 (+0100), Yassine Chaouche wrote:
> I tried to achieve the same w/o using apt-cache, but couldn't.
>
> My failed attempts were :
>
>
> 1/
> 16:37:5
Hello there,
I am exploring the possibilities of grep-dctrl.
My current experiment is to try and show the description of a
package that is not necessarily installed.
I have defined a package.describe
function in my .bashrc that does
On 22/10/2022 20:23, Gary Dale wrote:
sed -i '//d' *.html
did the trick.
I would suggest you to use more specific pattern to avoid removing of
meaningful text due to a lost newline character:
sed -i -e '/^\s*]*>\s*$/d'
"." in regexp may be a source of surprises (or catastrophic backtr
ginning of a word.
'\>'
Matches the end of a word.
but it's next to impossible to keep track of whether you're in a
section that's speaking POSIX, GNU, or some mid-20th century tradition.
I feel obliged at this point to mention that parsing HTML with regular
e
On Sat, Oct 22, 2022 at 10:32:24AM +0700, Max Nikulin wrote:
> On 22/10/2022 02:09, The Wanderer wrote:
> >
> > 'info sed', section 'sed regular expressions', subsection 'regular
> > expression extensions':
>
> While a reader may find more interesting stuff lying around while traveling
> by this
On 22/10/2022 02:09, The Wanderer wrote:
'info sed', section 'sed regular expressions', subsection 'regular
expression extensions':
While a reader may find more interesting stuff lying around while
traveling by this path, there is a shorthand
info "(sed) regexp extensions"
and alternatives
On 2022-10-21 at 16:16, Greg Wooledge wrote:
> On Fri, Oct 21, 2022 at 03:09:32PM -0400, The Wanderer wrote:
>
>> IOW, each seems to be half of the usual '\b' (edge of a word) set.
>> With the default sed behavior (not sure whether that's basic
>> regular expressions or extended regular expressio
On Fri, Oct 21, 2022 at 03:09:32PM -0400, The Wanderer wrote:
> IOW, each seems to be half of the usual '\b' (edge of a word) set. With
> the default sed behavior (not sure whether that's basic regular
> expressions or extended regular expressions, in the nomenclature of the
> info document), you c
or whatever
might really help. As it is, unless you're looking at a real book,
you get a table like:
'\s'
Matches whitespace characters (spaces and tabs). Newlines embedded
in the pattern/hold spaces will also match:
'\S'
Matches non-whit
On 2022-10-21 at 14:15, Greg Wooledge wrote:
> So... yeah, \< and/or \> clearly have some special meaning to GNU
> sed. Good luck figuring out what that is.
'info sed', section 'sed regular expressions', subsection 'regular
expression extensions':
>> '\<'
>> Matches the beginning of a word.
o-width string between the last non-word character
and the first word character ("<") and that one between the last word
character and the following non-word character (">"). PCRE has those,
too.
> For Gary's actual problem, simply removing the backslashes where t
uck figuring out what that is.
For Gary's actual problem, simply removing the backslashes where they're
not wanted would be a good start. Actually learning sed could be step 2.
I feel obliged at this point to mention that parsing HTML with regular
expressions is a fool's errand, and that sed should not be the tool of
choice here. Nor should grep, nor any other RE-based tool. This goes
triple when one doesn't even know the correct syntax for their RE.
https://stackoverflow.com/q/1732348
On Fri, Oct 21, 2022 at 01:50:29PM -0400, Greg Wooledge wrote:
> On Fri, Oct 21, 2022 at 01:21:44PM -0400, Gary Dale wrote:
> > sed -i -s 's/\s*\//g' history.html
> >
> > Unfortunately, the replacement doesn't remove the line but rather leaves me
> > with:
> >
> > <;">
>
> The 's' c
On Fri, Oct 21, 2022 at 01:21:44PM -0400, Gary Dale wrote:
> I'm hoping someone can tell me what I'm doing wrong. I have a line in a lot
> of HTML files that I'd like to remove. The line is:
>
>
>
> I'm testing the sed command to remove it on just one file. When it works,
> I'll run
On Fri, Oct 21, 2022 at 01:21:44PM -0400, Gary Dale wrote:
> sed -i -s 's/\s*\//g' history.html
>
> Unfortunately, the replacement doesn't remove the line but rather leaves me
> with:
>
> <;">
The 's' command in sed doesn't remove lines. It performs a substitution
within a line.
T
I'm hoping someone can tell me what I'm doing wrong. I have a line in a
lot of HTML files that I'd like to remove. The line is:
I'm testing the sed command to remove it on just one file. When it
works, I'll run it against *.html. My command is:
sed -i -s 's/\s*\//g' history.ht
Hello,
of course, there are different ways to solve this, i like the perl
approach. Only since i myself am not all that familiar with the
language, i'd like to add 2 pointers:
(M)AWK scripting language can do similar things (read syslog once, loop
over regular expressions and output anything you w
On 3/06/22 07:17, Greg Wooledge wrote:
On Thu, Jun 02, 2022 at 03:12:23PM -0400, duh wrote:
> > Jim Popovitch wrote on 28/05/2022 21:40:
> > > I have a file of regex patterns and I use grep like so:
> > >
> > > ~$ grep -f patterns.txt /var/log/syslog
>
On 6/2/22 22:50, Will Mengarini wrote:
* David Christensen [22-06/02=Th 19:18 -0700]:
[...]
Now I can almost match your prompt -- there is a dash before 'bash':
2022-06-02 19:05:10 dpchrist@laalaa ~
$ PS1="\\h/${TTY#/dev/} \\s$SHLVL \\w \\A \$?\\\$"
laalaa/pts/8 -bash1 ~ 19:08 0$
The dash see
* David Christensen [22-06/02=Th 19:18 -0700]:
> [...]
> Now I can almost match your prompt -- there is a dash before 'bash':
>
> 2022-06-02 19:05:10 dpchrist@laalaa ~
> $ PS1="\\h/${TTY#/dev/} \\s$SHLVL \\w \\A \$?\\\$"
> laalaa/pts/8 -bash1 ~ 19:08 0$
>
> The dash seems to be coming from the '\s
PS1:
2022-06-02 17:39:09 dpchrist@laalaa ~
$ grep PS1 .profile
export PS1='\n\D{%Y-%m-%d %H:%M:%S} '${USER}'@\h \w\n\$ '
Variable expansions *are* performed when PS1 is evaluated. So, you
could simply do:
PS1='stuff $USER more stuff'
That will delay the expansio
17:39:09 dpchrist@laalaa ~
> $ grep PS1 .profile
> export PS1='\n\D{%Y-%m-%d %H:%M:%S} '${USER}'@\h \w\n\$ '
Variable expansions *are* performed when PS1 is evaluated. So, you
could simply do:
PS1='stuff $USER more stuff'
That will delay the expansion of U
On 6/2/22 18:35, Will Mengarini wrote:
* David Christensen [22-06/02=Th 18:01 -0700]:
On 6/2/22 17:12, Will Mengarini wrote:
* David Christensen [22-06/02=Th 15:50 -0700]:
On 6/2/22 15:13, Will Mengarini wrote:
In this transcript, the number before the prompt-ending '$' is $?:
y driver:
>
> 2022-06-02 17:38:55 dpchrist@laalaa ~
> $ cat /etc/debian_version ; uname -a ; dpkg-query -W bash
> 11.3
> Linux laalaa 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64
> GNU/Linux
> bash 5.1-2+b3
>
> This is my PS1. '\u' does not wor
5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29)
x86_64 GNU/Linux
bash5.1-2+b3
This is my PS1. '\u' does not work on all of Debian, FreeBSD, Cygwin,
and macOS, so the expansion of ${USER} is inserted between two string
literals when .profile runs and sets PS1:
* David Christensen [22-06/02=Thu 15:50 -0700]:
> On 6/2/22 15:13, Will Mengarini wrote:
>> * Greg Wooledge [22-05/28=Sa 17:11 -0400]:
>>> [...]
>>> #!/usr/bin/perl
>>> use strict; use warnings;
>>> [...]
>>> open PATS, ">> [...]
>>
>> You need "or die", not "|| die", because of precedence: what
On 6/2/22 15:13, Will Mengarini wrote:
* Greg Wooledge [22-05/28=Sa 17:11 -0400]:
[...]
#!/usr/bin/perl
use strict; use warnings;
[...]
open PATS, "
You need "or die", not "|| die", because of precedence: what you coded
checks whether "
+1 That is a good explanation of a Perl fine point/ go
* Greg Wooledge [22-05/28=Sa 17:11 -0400]:
> [...]
> #!/usr/bin/perl
> use strict; use warnings;
> [...]
> open PATS, " [...]
You need "or die", not "|| die", because of precedence: what you coded
checks whether "
perl -le"print unpack '%C*',MENGARINI"
On Thu, Jun 02, 2022 at 03:12:23PM -0400, duh wrote:
> > > Jim Popovitch wrote on 28/05/2022 21:40:
> > > > I have a file of regex patterns and I use grep like so:
> > > >
> > > > ~$ grep -f patterns.txt /var/log/syslog
> > > >
On 5/29/22 9:44 AM, David Wright wrote:
On Sun 29 May 2022 at 15:02:35 (+0200), Jörg-Volker Peetz wrote:
Jim Popovitch wrote on 28/05/2022 21:40:
Not exactly Debian specific, but hoping that someone here can help.
I have a file of regex patterns and I use grep like so:
~$ grep -f
On Sat, 2022-05-28 at 17:11 -0400, Greg Wooledge wrote:
> On Sat, May 28, 2022 at 04:02:39PM -0400, The Wanderer wrote:
> > On 2022-05-28 at 15:40, Jim Popovitch wrote:
> > > I have a file of regex patterns and I use grep like so:
> > >
> > > ~$
On Sun 29 May 2022 at 15:02:35 (+0200), Jörg-Volker Peetz wrote:
> Jim Popovitch wrote on 28/05/2022 21:40:
> > Not exactly Debian specific, but hoping that someone here can help.
> >
> > I have a file of regex patterns and I use grep like so:
> >
> > ~$ gre
Jim Popovitch wrote on 28/05/2022 21:40:
Not exactly Debian specific, but hoping that someone here can help.
I have a file of regex patterns and I use grep like so:
~$ grep -f patterns.txt /var/log/syslog
What I'd like to get is a listing of all lines, specifically the line
numbers o
On 2022-05-28 at 17:11, Greg Wooledge wrote:
> On Sat, May 28, 2022 at 04:02:39PM -0400, The Wanderer wrote:
>
>> On 2022-05-28 at 15:40, Jim Popovitch wrote:
>> > I have a file of regex patterns and I use grep like so:
>> >
>> >~$ grep -f patterns.t
On Sat, May 28, 2022 at 04:02:39PM -0400, The Wanderer wrote:
> On 2022-05-28 at 15:40, Jim Popovitch wrote:
> > I have a file of regex patterns and I use grep like so:
> >
> >~$ grep -f patterns.txt /var/log/syslog
> >
> > What I'd like to get is a
On 2022-05-28 at 15:40, Jim Popovitch wrote:
> Not exactly Debian specific, but hoping that someone here can help.
>
> I have a file of regex patterns and I use grep like so:
>
>~$ grep -f patterns.txt /var/log/syslog
>
> What I'd like to get is a listing of a
Not exactly Debian specific, but hoping that someone here can help.
I have a file of regex patterns and I use grep like so:
~$ grep -f patterns.txt /var/log/syslog
What I'd like to get is a listing of all lines, specifically the line
numbers of the regexps in patterns.txt, that
Greg Wooledge wrote:
> On Mon, Aug 27, 2018 at 10:36:12AM -0400, songbird wrote:
>> me@ant(25)$ env | grep -F "-g"
>> grep: invalid option -- 'g'
>
> You want either -- or -e.
>
> grep -F -- -g
> grep -F -e -g
i just found it interestin
What's tripping you up is that some processing is being done by the
shell before grep ever sees your pattern. Taking that into account,
what grep is seeing is:
songbird writes:
> me@ant(25)$ env | grep -F "-g"
grep -F -g
> grep: invalid option -- 'g'
> Usa
On Mon, Aug 27, 2018 at 11:26:12AM -0400, Greg Wooledge wrote:
> On Mon, Aug 27, 2018 at 11:20:42AM -0400, Roberto C. Sánchez wrote:
> > env |grep [-]g
>
> Fails if there is a file named -g in the current directory, as that
> matches the unquoted glob and causes it to expa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Aug 27, 2018 at 11:19:25AM -0400, Greg Wooledge wrote:
> On Mon, Aug 27, 2018 at 10:36:12AM -0400, songbird wrote:
> > me@ant(25)$ env | grep -F "-g"
> > grep: invalid option -- 'g'
>
> You want eith
songbird (2018-08-27):
> me@ant(25)$ env | grep -F "-g"
> grep: invalid option -- 'g'
Maybe what you want is an explanation rather than just a solution.
Quotes are for the shell: they protect arguments that contain special
characters, so that commands get them as is.
On Mon, Aug 27, 2018 at 11:20:42AM -0400, Roberto C. Sánchez wrote:
> env |grep [-]g
Fails if there is a file named -g in the current directory, as that
matches the unquoted glob and causes it to expand. Also fails if failglob
is turned on, whether the file exists or not (fails differently
On Mon, Aug 27, 2018 at 10:36:12AM -0400, songbird wrote:
> me@ant(25)$ env | grep -F "-g"
> grep: invalid option -- 'g'
> Usage: grep [OPTION]... PATTERN [FILE]...
> Try 'grep --help' for more information.
> me@ant(26)$ env | grep -F '-g&#x
On Mon, Aug 27, 2018 at 10:36:12AM -0400, songbird wrote:
> me@ant(25)$ env | grep -F "-g"
> grep: invalid option -- 'g'
You want either -- or -e.
grep -F -- -g
grep -F -e -g
me@ant(25)$ env | grep -F "-g"
grep: invalid option -- 'g'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
me@ant(26)$ env | grep -F '-g'
grep: invalid option -- 'g'
Usage: grep [OPTION]... PATTERN [FILE]...
Try &
That strikes me as being just a touch too complex for grep. It may well
be doable, but you'll probably have an easier time using AWK (possibly not
what you wanted to hear, but it's well worth learning). The object of the
game would be to count the number of signs on each line and
On Sun, 8 Jan 2017 12:40:34 +0300
Reco wrote:
> or, if you need whole words (i.e. need to exclude spaces):
>
> egrep '^[^ ]$' file1
Self-edit. Of course it's:
egrep '^[^ ]{5}$' file1
Reco
Hi.
On Sun, 08 Jan 2017 10:11:26 +0100
Hans wrote:
> Hi all,
>
> I have a little problem with using grep.
>
> The problem:
>
> I have a wordlist with 3,5 Mio words in ASCII. No I want filter out all words
> with 5,6,
> 7, 8, 9 and 10 signs in seperate l
Hi all,
I have a little problem with using grep.
The problem:
I have a wordlist with 3,5 Mio words in ASCII. No I want filter out all words
with 5,6,
7, 8, 9 and 10 signs in seperate lists. The wordlist contains all sort of
signs, like
alphanumeric, control signs like "^", &quo
e:]]/ { /^[^[:space:]]/d ; p
>> }' /usr/share/misc/pci.ids
>>
>> Wrapping to script which get an argument is easy
>>
>> Regards
>>
>
> Thanks for your answer, and the next question pops in.
>
> Is there a "rule" when I use perl, awk, sed, grep, c
quot;vendor"
" {p=1;} p' /usr/share/misc/pci.ids
With sed:
sed -ne '/^0e11/p' -e '/^0e11/,/^[^[:space:]]/ { /^[^[:space:]]/d ; p
}' /usr/share/misc/pci.ids
Wrapping to script which get an argument is easy
Regards
Thanks for your answer, and the next question p
In article R. Clayton
wrote:
> and I've been getting a lot of this lately:
> $ grep ^Subject: cbtm
> Binary file cbtm matches
> whereas before (a month or so ago) I used to get actual matches on std-out.
> It's easy enough to work around like so
> $ sed
en getting a lot of this lately:
$ grep ^Subject: cbtm
Binary file cbtm matches
$
whereas before (a month or so ago) I used to get actual matches on std-out.
It's easy enough to work around like so
$ sed -n -e '/^Subject:/p' < cbtm
Subject: Re: PTFACULTY: FTFACUL
s "better" and it can matter. I guess I used ls too
often with grep instead of only using ls , until somebody mentioned
it. I guess such "mistakes" should be mentioned on open mailing lists.
Next time somebody googles for grep s/he shouldn't find an less good
example b
On 20.Okt.2013, at 00:51, Ralf Mardorf wrote:
>
>
> On Sun, 2013-10-20 at 03:42 +0500, Muhammad Yousuf Khan wrote:
>>cat /etc/passwd | grep ykhan
>>ykhan:x:19000:19000:ykhan,,,:/home/ykhan:/bin/bash
>
> [rocketmouse@archlinux ~]$ grep rocketmouse
On Sun, 2013-10-20 at 03:42 +0500, Muhammad Yousuf Khan wrote:
> cat /etc/passwd | grep ykhan
> ykhan:x:19000:19000:ykhan,,,:/home/ykhan:/bin/bash
[rocketmouse@archlinux ~]$ grep rocketmouse /etc/passwd
rocketmouse:x:1000:1000::/home/rocketmouse:/bin/bash
IOW if you us
On Thu, 05 May 2011 05:10:53 -0700, Regid Ichira wrote:
> $ apt-cache --names-only search apm | grep sleepd
> sleepd - puts an inactive or low battery laptop to sleep
>
> Am I right that, according to man apt-cache, mentioning sleepd is a bug?
(...)
Yep, well... kind of. Alre
$ apt-cache --names-only search apm | grep sleepd
sleepd - puts an inactive or low battery laptop to sleep
Am I right that, according to man apt-cache, mentioning sleepd is a bug?
$ man apt-cache | grep -A20 ' search regex' | head
search reg
p with a command line like this:
>>
>> $ grep [_a-zA-Z][_a-zA-Z0-9]file1 file2 file3
...
> The shell will expand the above into space separated values, based on
> matches to the glob pattern. The first match will become the pattern
> used by grep, searched for in the remaining file nam
ht I
>> wanted it to do. What is puzzling to me is that my hard disk usage
>> peaked, my cpu jumped, and grep took almost two minutes to return an
>> exit code of 1 (no match). :-/
>
> What was your exact command line? Did you quote the regular expression?
> My guess is
On 20101109_071001, ~Stack~ wrote:
> Hello everyone!
>
> I ran into a strange issue with grep and I was hoping someone could
> explain what I feel is an oddity.
>
> I was trying to match a word that starts with either a _ or a letter
> followed by any number of _, letters,
isk usage
> peaked, my cpu jumped, and grep took almost two minutes to return an
> exit code of 1 (no match). :-/
What was your exact command line? Did you quote the regular expression?
My guess is that the shell interpreted the '*' character for you and you
ended up with a command li
Hello everyone!
I ran into a strange issue with grep and I was hoping someone could
explain what I feel is an oddity.
I was trying to match a word that starts with either a _ or a letter
followed by any number of _, letters, or numbers. (eg: Good = Asdf1,
_aSD1. Bad: 9_asD ). My test text file
On Fri, Sep 17, 2010 at 11:07:53PM -0600, Bob Proulx wrote:
> Albretch Mueller wrote:
> But newer POSIX standard find can use a {} + to launch grep once and
> to pass as many files on the command line as the system allows. That
> is faster since grep is launched only as many tim
Albretch Mueller wrote:
> $ find -name '*.extension' -exec grep -H 'pattern' {} \;
Using {} \; is the old way. That invokes grep once per file. That
works but is slower and less efficient than it could be because it
takes a little bit of time to launch grep.
But newer
On Fri, 17 Sep 2010 14:08:18 -0400 (EDT), Albretch Mueller wrote:
>
> I need to:
>~ search for files using a pattern (say all files with a certain extension)
>~ then search inside each of the found files for a word or regexp pattern
>~ You could do this using find, ca
On Fri, Sep 17, 2010 at 06:32:06PM +, Albretch Mueller wrote:
> > if you need certain extension, you don't even need cat and find, it's all
> > about grep:
>
> > $ grep 'string' *.extension
> ~
> The thing is that I need to know in whi
Albretch Mueller wrote:
> I need to:
> ~
> search for files using a pattern (say all files with a certain extension)
> ~
> then search inside each of the found files for a word or regexp pattern
> ~
> You could do this using find, cat and grep in a script, but I was
> if you need certain extension, you don't even need cat and find, it's all
> about grep:
> $ grep 'string' *.extension
~
The thing is that I need to know in which file the pattern was found
and as you guys suggested:
~
$ find -name '*.extension' -
On Fri, 17 Sep 2010 18:08:18 +, Albretch Mueller wrote:
> I need to:
> ~
> search for files using a pattern (say all files with a certain
> extension)
> ~
> then search inside each of the found files for a word or regexp pattern
> ~
> You could do this using find,
and find, it's all about grep:
$ grep 'string' *.extension
> ~
> then search inside each of the found files for a word or regexp pattern
But if you really want to use find, here's something you may try:
$ find -name '*.extension' -exec grep -H 'pattern&#
Hi Albrecht,
On Fri, Sep 17, 2010 at 06:08:18PM +, Albretch Mueller wrote:
> search for files using a pattern (say all files with a certain extension)
> then search inside each of the found files for a word or regexp pattern
> You could do this using find, cat and grep in a scri
I need to:
~
search for files using a pattern (say all files with a certain extension)
~
then search inside each of the found files for a word or regexp pattern
~
You could do this using find, cat and grep in a script, but I was
wondering about how could you do it with a oneliner
~
Thanks
Zhang Weiwu wrote:
> Bob McGowan wrote:
> > My point is that changing only the LANG environment variable changed the
> > way 'grep' dealt with the newline character.
>
> You are right this really look like a problem. Where should I file the
> bug? The gnu proje
On 2010年08月07日 06:41, Bob McGowan wrote:
> My point is that changing only the LANG environment variable changed the
> way 'grep' dealt with the newline character.
You are right this really look like a problem. Where should I file the
bug? The gnu projects management looks
1 - 100 of 546 matches
Mail list logo
