Match the full stop and quotation mark literally with regexp by using egrep.
Hongyi Zhao
I want to match full stop, i.e., U+002E and quotation mark, i.e.,
U+0022 literally with regexp by using egrep.
Should I use the \ (reverse solidus) as the prepositional modifier
Character or not? For detail, should I use \. and \" or . and "
only?
Best regards.
--
.: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :.
OldSchool
abcd."
asc." a
then either of the following will find both lines:
grep \.\" testfile
grep '\."' testfile
in either case, the \. is so that the "." is taken literally. in
first example, the \" is used to allow the shell to take the double-
quote, while in the second, the single-quotes cause the shell take the
double quote literally.
a little experimentation on your part should provide the solution that
works for you.
OldSchool
> On Dec 23, 8:56 am, Hongyi Zhao <hongyi.z...@gmail.com> wrote:> Hi all,
>
> > I want to match full stop, i.e., U+002E and quotation mark, i.e.,
> > U+0022 literally with regexp by using egrep.
>
> > Should I use the \ (reverse solidus) as the prepositional modifier
> > Character or not? For detail, should I use \. and \" or . and "
> > only?
>
> > Best regards.
> > --
> > .: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :.
>
> given a file containing:
>
> abcd."
> asc." a
>
> then either of the following will find both lines:
>
> grep \.\" testfile
>
> grep '\."' testfile
>
>
and I suspect the second is what you're really after, as the first
fails miserably, taking the "." to be any character
Rakesh Sharma
The dot can be matched by either escaping it via a backslash or
placing
it inside the metacharacter classes, like so:
egrep '\.'
egrep "\\."
egrep \\.
or more simply,
egrep '[.]'
while the double quotation mark is matched by itself:
egrep '"'
or,
egrep '["]'
-- Rakesh
Kaz Kylheku
> Hi all,
>
> I want to match full stop, i.e., U+002E and quotation mark, i.e.,
> U+0022 literally with regexp by using egrep.
egrep is long obsolete; use grep -E.
> Should I use the \ (reverse solidus) as the prepositional modifier
> Character or not? For detail, should I use \. and \" or . and "
> only?
The quotation mark isn't special in regexps, but . is.
However, quotation is special in the shell language that you're
using to invoke egrep. And so is the backslash, depending on
the lexical context.
If your regex pattern doesn't contain a single quote, then
wrap it in single quotes. That's the simplest solution:
grep -E 'pattern with \. period and " quote' ...
In double quotes, the backslash is interpreted by the shell. So you must write
two backslashes to pass a single backslash to the command as part of the
argument.
grep -E "pattern with \\. period and \" quote" ...
See, the \\ shell syntax means that a single \ is seen by grep.
The \" shell syntax means that the " character is seen by grep.
Kevin Collins
> On 2009-12-23, Hongyi Zhao <hongy...@gmail.com> wrote:
>> Hi all,
>>
>> I want to match full stop, i.e., U+002E and quotation mark, i.e.,
>> U+0022 literally with regexp by using egrep.
>
> egrep is long obsolete; use grep -E.
Uh, not really:
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ grep -E blah /etc/profile
grep: illegal option -- E
Usage: grep -hblcnsviw pattern file . . .
$ egrep blah /etc/profile
$
Now, on HP-UX and RedHat Linux you would be correct :)
Kevin
pk
> In double quotes, the backslash is interpreted by the shell.
Only if it's followed by some special characters, and "." is not one of
those.
> So you must write two backslashes to pass a single backslash to the
> command as part of the argument.
>
> grep -E "pattern with \\. period and \" quote" ...
>
> See, the \\ shell syntax means that a single \ is seen by grep.
True, but
"pattern with \. period and \" quote"
would get the same result here.
Kaz Kylheku
> On 2009-12-23, Kaz Kylheku <kkyl...@gmail.com> wrote:
>> On 2009-12-23, Hongyi Zhao <hongy...@gmail.com> wrote:
>>> Hi all,
>>>
>>> I want to match full stop, i.e., U+002E and quotation mark, i.e.,
>>> U+0022 literally with regexp by using egrep.
>>
>> egrep is long obsolete; use grep -E.
>
> [snip]
>
> Uh, not really:
>
> Sun Microsystems Inc. SunOS 5.10 Generic January 2005
> $ grep -E blah /etc/profile
> grep: illegal option -- E
What does your PATH look like?
I'm not that familiar with Solaris, but I do know that it separates its
command-level standard compliance by providing multiple /bin directories,
which have to be searched in the right order.
E.g. for POSIX.1-2001 compliance, for instance, it looks like you have to
search in this order: /usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/bin
(Correct, if wrong).
Maybe this fixes the standard compliance in grep.
> Usage: grep -hblcnsviw pattern file . . .
> $ egrep blah /etc/profile
> $
>
> Now, on HP-UX and RedHat Linux you would be correct :)
I'm going by The Single Unix Specification, Issue 6:
http://www.opengroup.org/onlinepubs/009695399/
There is no ``hit'' searching for the term ``egrep''
at all. So it looks like it has been completely removed now.
I remember it was already marked as an obsolescent feature in the 1990 POSIX.2.
Today, egrep is no longer a Unix command. The -E option is a required feature
of grep.
Twenty years is more than enough time to straighten out your grep!
Hongyi Zhao
<shar...@hotmail.com> wrote:
> egrep "\\."
> egrep \\.
What's the function of the first and the second backslashes
respectively?
Hongyi Zhao
>> In double quotes, the backslash is interpreted by the shell.
>
>Only if it's followed by some special characters, and "." is not one of
>those.
So, any hints on the set of these special characters?
Hongyi Zhao
<kkyl...@gmail.com> wrote:
>In double quotes, the backslash is interpreted by the shell. So you must write
>two backslashes to pass a single backslash to the command as part of the
>argument.
>
> grep -E "pattern with \\. period and \" quote" ...
>
>See, the \\ shell syntax means that a single \ is seen by grep.
>
>The \" shell syntax means that the " character is seen by grep.
My issue is: why you only use double backslashes before full stop, but
single backslash before quotation mark?
Seebs
> On Wed, 23 Dec 2009 22:38:15 +0000 (UTC), Kaz Kylheku
><kkyl...@gmail.com> wrote:
>>In double quotes, the backslash is interpreted by the shell. So you must write
>>two backslashes to pass a single backslash to the command as part of the
>>argument.
>> grep -E "pattern with \\. period and \" quote" ...
>>See, the \\ shell syntax means that a single \ is seen by grep.
>>The \" shell syntax means that the " character is seen by grep.
> My issue is: why you only use double backslashes before full stop, but
> single backslash before quotation mark?
The single backslash before the quotation mark causes the shell to treat
the quotation mark as a regular character, and pass it on to grep.
The double backslashes before the period cause the shell to treat the second
backslash as a regular character, and pass it on to grep. The period is
already a regular character to the shell.
Thus, the actual string grep gets is:
pattern with \. period and " quote
and the backslash it was given serves to escape the period, which has
special meaning to grep (but not to the shell).
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Ben Finney
> Thus, the actual string grep gets is:
> pattern with \. period and " quote
> and the backslash it was given serves to escape the period, which has
> special meaning to grep (but not to the shell).
This can be clarified by testing with the ‘echo’ command. That way you
can see what transformations happened to the shell arguments before the
command actually got executed.
$ echo grep foo bar baz
grep foo bar baz
$ echo grep foo 'bar' "baz"
grep foo bar baz
$ echo grep foo \'bar "baz"
grep foo 'bar baz
$ echo grep foo .bar baz.
grep foo .bar baz.
$ echo grep foo \.bar baz\"
grep foo .bar baz"
$ echo grep foo \\.bar baz\"
grep foo \.bar baz"
It's a good idea to experiment with the command line you intend to run,
by prefixing it with ‘echo’ and checking that the command arguments are
transformed as you expect them to be.
--
\ “Don't be afraid of missing opportunities. Behind every failure |
`\ is an opportunity somebody wishes they had missed.” —Jane |
_o__) Wagner, via Lily Tomlin |
Ben Finney
Seebs
> Seebs <usenet...@seebs.net> writes:
>> Thus, the actual string grep gets is:
>> pattern with \. period and " quote
>> and the backslash it was given serves to escape the period, which has
>> special meaning to grep (but not to the shell).
> This can be clarified by testing with the ?echo? command. That way you
> can see what transformations happened to the shell arguments before the
> command actually got executed.
Except on shells where echo "helpfully" translates \.
One of the best things I learned from writing a book about the shell is
that printf is substantially more portable-and-stable than echo.
Kaz Kylheku
><shar...@hotmail.com> wrote:
>
>> egrep "\\."
>> egrep \\.
>
> What's the function of the first and the second backslashes
> respectively?
Read the "Shell Command Language" chapter of The Single Unix
Specification (available online).
Hongyi Zhao
<ben+...@benfinney.id.au> wrote:
> $ echo grep foo bar baz
> grep foo bar baz
> $ echo grep foo 'bar' "baz"
> grep foo bar baz
> $ echo grep foo \'bar "baz"
> grep foo 'bar baz
> $ echo grep foo .bar baz.
> grep foo .bar baz.
> $ echo grep foo \.bar baz\"
> grep foo .bar baz"
> $ echo grep foo \\.bar baz\"
> grep foo \.bar baz"
>
>It's a good idea to experiment with the command line you intend to run,
>by prefixing it with ‘echo’ and checking that the command arguments are
>transformed as you expect them to be.
Thanks a lot for you excellent idea! I do a further test based on
your idea as follows:
In this test, I use the following four forms:
$ echo grep foo [\."]bar baz\"
>
$ echo grep foo [."]bar baz\"
>
$ echo grep foo [.\"]bar baz\"
grep foo [."]bar baz"
$ echo grep foo [\.\"]bar baz\"
grep foo [."]bar baz"
You can see the first two fails to give any results on the stdout,
why?
Jon LaBadie
> On Wed, 23 Dec 2009 22:49:18 +0000, pk <p...@pk.invalid> wrote:
>
>>> In double quotes, the backslash is interpreted by the shell.
>> Only if it's followed by some special characters, and "." is not one of
>> those.
>
> So, any hints on the set of these special characters?
>
Inside double quote variable substitution, command substitution, and
numeric evaluation are all active. Their syntax starts with dollar sign ($)
and an alternative for command substitution starts with back quote (`).
The dollar sign and back quote are turned into literals with the backslash.
A double quote ends the quotation, so a backslash is used to give a literal
double quote.
Finally, most places inside double quotes a backslash is literal. But if
you need a literal backslash in front of a $, `, or ", you have to put in
two backslashes.
Bill Marcum
>
> $ echo grep foo [."]bar baz\"
>>
>
> $ echo grep foo [.\"]bar baz\"
> grep foo [."]bar baz"
>
> $ echo grep foo [\.\"]bar baz\"
> grep foo [."]bar baz"
>
> You can see the first two fails to give any results on the stdout,
> why?
>
pattern, and there are no filenames matching that pattern. In the
first one, the closing bracket is quoted, so the expression is incomplete
and the shell gives a ">" prompt.
pk
> On Wed, 23 Dec 2009 22:49:18 +0000, pk <p...@pk.invalid> wrote:
>
>>> In double quotes, the backslash is interpreted by the shell.
>>
>>Only if it's followed by some special characters, and "." is not one of
>>those.
>
> So, any hints on the set of these special characters?
It should be in the man page of your shell. Bash manual says:
"Enclosing characters in double quotes preserves the literal value of all
characters within the quotes, with the exception of $, `, \, and, when
history expansion is enabled, !. The characters $ and ` retain their special
meaning within double quotes. The backslash retains its special meaning
only when followed by one of the following characters: $, `, ", \, or
<newline>. A double quote may be quoted within double quotes by preceding
it with a backslash. If enabled, history expansion will be performed
unless an ! appearing in double quotes is escaped using a backslash. The
backslash preceding the ! is not removed."