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
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
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
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
nocaseglob off
nullgloboff
unicorn:~$ shopt -s nullglob
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?
> > >
>
> (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. $ 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 addres
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 seems
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. $ apt
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
> 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`
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
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 a s
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
: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
Those are the wrong
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:50 ~ -1- $
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
's speaking POSIX, GNU, or some mid-20th century tradition.
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 eve
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
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
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
'\s'
Matches whitespace characters (spaces and tabs). Newlines embedded
in the pattern/hold spaces will also match:
'\S'
Matches non-whitespace characters.
'\<'
Matches the beginning of a word.
'\>'
Matches the end of a word.
but it's next to impossible
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
nd 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 they're
> not wanted would be a good start. Actually learning sed could be step 2.
Exactly.
>
ashes 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'
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.
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'
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
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
* 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
-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 expansion of USER (which by the way is a BSD-ism
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 USER (which by the way is a BSD-ism)
unti
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 $?:
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 work on all of Debian, FreeBSD,
> Cygwin
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:
2022-06-02 17:39:09 dpchrist@laalaa ~
$
* 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/
* 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
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 l
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 al
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 match
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 interesting that
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'
> Usage: grep [OPTIO
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 e
-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 either -- or -
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.
For e
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 differen
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'
> grep: invalid option
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 'grep --help' for more information.
me@an
Le Wed, 8 Mar 2017 15:45:47 +0100,
G2PC a écrit :
> Bernard m'a transmis son dossier /etc/zsh
> Le changement fait que l'erreur Avertissement : GREP_OPTIONS doit être
> abandonnée n'apparait plus.
> Je n'ai par contre pas d'informations complémentaire à fournir, pour
> la
Le 08/03/2017 à 15:26, G2PC a écrit :
> Le 08/03/2017 à 14:28, Francois Lafont a écrit :
>> Bonjour,
>>
>> On 03/08/2017 12:36 PM, G2PC wrote:
>>
>>> *Vu sur un forum, ajouter à la fin de ~/.zshrc*
>>>
>>> alias grep="/usr/bin/grep $
Le 08/03/2017 à 14:28, Francois Lafont a écrit :
> Bonjour,
>
> On 03/08/2017 12:36 PM, G2PC wrote:
>
>> *Vu sur un forum, ajouter à la fin de ~/.zshrc*
>>
>> alias grep="/usr/bin/grep $GREP_OPTIONS"
>> unset GREP_OPTIONS
>>
>> Semble ne
r
> non négligeable de tomber sur la ligne coupable ;)) :
>
> find ~ -maxdepth 1 -type f -name '*rc' -exec grep --color -nH
> 'GREP_OPTIONS' '{}' '+'
Ah mince, y'a aussi le fichier ~/.profile à regarder, et
y'en a sûrement d'autres encore. La page man de ton shell
te donnera sans dou
Bonjour,
On 03/08/2017 12:36 PM, G2PC wrote:
> *Vu sur un forum, ajouter à la fin de ~/.zshrc*
>
> alias grep="/usr/bin/grep $GREP_OPTIONS"
> unset GREP_OPTIONS
>
> Semble ne rien changer chez moi.
>
>
>
> J'ai toujours l'erreur : grep: Avertisseme
Bonjour,
Lorsque je grep j'ai le message d'erreur suivant :
dpkg -l |grep lockfile-progs
grep: Avertissement : GREP_OPTIONS doit être abandonnée ; veuillez utiliser un
alias ou un script
Bernard avait ouvert un post il y a deux ans sur la même erreur :
http
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 print only
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 <hans.ullr...@loop.de> 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,
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
{ /^[^[: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, gre
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 pops in.
Is there a "rule
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: FTFACULTY: When saying "Nou
In article <qvgvx-m...@gated-at.bofh.it> R. Clayton <rclay...@monmouth.edu>
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.
&g
On 2015-05-11 17:30:15 +0200, Sébastien NOBILI wrote:
Le lundi 11 mai 2015 à 17:01, Bernard Schoenacker a écrit :
Que retourne la commande suivante ?
echo $GREP_OPTIONS
je n'obtien aucune réponse
OK, donc la variable n'est pas définie, le problème ne vient pas de là.
Non,
problème ne vient pas de
là.
Le lundi 11 mai 2015 à 16:29, Bernard Schoenacker a écrit :
j'ai regardé ceci :
apt-cache policy grep
grep:
Installé : 2.21-1
Candidat : 2.21-1
Table de version :
*** 2.21-1 0
1 http://ftp.fr.debian.org/debian/ experimental/main
bonjour,
je souhaiterai connaître la commande qui remplace grep ...
exemple :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée ; veuillez
utiliser un alias ou un script
zsh: done lspci |
slt
bernard
--
Lisez la FAQ de la liste avant de poser une question
Salut Bernard,
Il n'y a pas de commande qui remplace grep :D (enfin si mais tu vois ce
que je veux dire =) )
Ton zsh déconne ou un caractère s'est peut etre glissé dans ton
copié/collé, c'est tout le problème des systèmes installés en français,
les logs d'erreurs sont eux aussi foireux
Le lundi 11 mai 2015 à 14:09, Bernard Schoenacker a écrit :
je souhaiterai connaître la commande qui remplace grep ...
Grep existe toujours (et ça devrait continuer…)
exemple :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée ; veuillez
utiliser un alias ou un
Le Mon, 11 May 2015 14:24:40 +0200,
Sébastien NOBILI sebnewslet...@free.fr a écrit :
Le lundi 11 mai 2015 à 14:09, Bernard Schoenacker a écrit :
je souhaiterai connaître la commande qui remplace grep ...
Grep existe toujours (et ça devrait continuer…)
exemple :
lspci | grep wifi
Le lundi 11 mai 2015 à 15:46, Bernard Schoenacker a écrit :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée ; veuillez
utiliser un alias ou un script
Tu dois avoir une variable GREP_OPTIONS dans laquelle tu as défini des
directives pour personnaliser le
Bernard donne
des infos sur les actions qui ont conduit à ce résultat
@+
On 05/11/2015 04:06 PM, Sébastien NOBILI wrote:
Le lundi 11 mai 2015 à 15:46, Bernard Schoenacker a écrit :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée ;
veuillez utiliser un
Le lundi 11 mai 2015 à 16:17, Bernard Schoenacker a écrit :
Le Mon, 11 May 2015 16:06:16 +0200,
Sébastien NOBILI sebnewslet...@free.fr a écrit :
Le lundi 11 mai 2015 à 15:46, Bernard Schoenacker a écrit :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée
2015 à 16:17, Bernard Schoenacker a écrit :
Le Mon, 11 May 2015 16:06:16 +0200,
Sébastien NOBILI sebnewslet...@free.fr a écrit :
Le lundi 11 mai 2015 à 15:46, Bernard Schoenacker a écrit :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée ;
veuillez utiliser un alias
a écrit :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée ;
veuillez utiliser un alias ou un script
Tu dois avoir une variable GREP_OPTIONS dans laquelle tu as
défini des directives pour personnaliser le comportement de
Grep
/11/2015 04:06 PM, Sébastien NOBILI wrote:
Le lundi 11 mai 2015 à 15:46, Bernard Schoenacker a écrit :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée ; veuillez
utiliser un alias ou un script
Tu dois avoir une variable GREP_OPTIONS dans laquelle tu as défini des
Le Mon, 11 May 2015 16:06:16 +0200,
Sébastien NOBILI sebnewslet...@free.fr a écrit :
Le lundi 11 mai 2015 à 15:46, Bernard Schoenacker a écrit :
lspci | grep wifi
grep: Avertissement : GREP_OPTIONS doit être abandonnée ;
veuillez utiliser un alias ou un script
Tu dois avoir
regardé ceci :
apt-cache policy grep
grep:
Installé : 2.21-1
Candidat : 2.21-1
Table de version :
*** 2.21-1 0
1 http://ftp.fr.debian.org/debian/ experimental/main amd64
Packages 100 /var/lib/dpkg/status
2.20-4.1 0
500 http://ftp.fr.debian.org/debian/ sid
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 by the original thread, but my hint
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 use grep
1 - 100 of 1159 matches
Mail list logo