[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38792: man grep

From: Stephane Chazelas
Subject: bug#38792: man grep
Date: Sun, 29 Dec 2019 18:56:30 +0000
User-agent: NeoMutt/20180716

2019-12-29 15:24:47 +0100, Martin Simons:
> martin@laptop:~/test$ grep 'Jantje*' school.txt
> Which delivers the desired output:
> Jantje

It also matches on Jantj? The * regexp operator matches 0 or
more of the preceding atom. So e* matches 0 or more "e"s. It's
not to confused with the "*" shell wildcard operator.

In effect, that's equivalent to

   grep Jantj school.txt

> martin@laptop:~/test$ grep Jantje* school.txt
> Delivering this undesired output:
> Jantjes:Jantje zag eens pruimen hangen
> Jantjes:en Jantje wilde pruimen plukken voor zijn moeder
> Jantjes:toen zei Jantjes moeder
> Jantjes:pas toch op Jantje!
> school.txt:Jantje
> school.txt:Ik las dat Jantje
> school.txt:Jantje voortaan op tijd op school komt,
> school.txt:Hoogachtend, Jantjes vader, Piet Bel.
> In trying to give more weight to the argument I pointed the students to the
> man page of grep, but it struck me that there is not a single reference to
> the need of using quotes in the search pattern. This does not help.

All grep receives is a list of arguments. That * needs to be
quoted for the shell not to treat it as a glob operator, not for

You'll find explanation of shell globbing (aka filename
generation, aka pathname expansion, aka filename expansion) and
the effect of quoting on it in your shell manual.

For the GNU shell, that's with:

   info bash 'filename expansion'

What needs to be quoted for a given shell varies with the shell
implementation, grep has nothing to do with that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]