[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Word boundary anchors \< and \> not parsed correctly on the right si
From: |
Greg Wooledge |
Subject: |
Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~ |
Date: |
Tue, 10 Jul 2018 09:09:06 -0400 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Tue, Jul 10, 2018 at 10:02:34AM -0300, Paulo Marcel Coelho Aragão wrote:
> It baffles me that literal \< \> are not evaluated correctly
>
> paulo:~$ [[ 'foo bar' =~ \<foo\> ]] && echo yes || echo no
> no
In this context, the backslashes serve only to "quote" the less-than
and greater-than signs. It's just like writing
[[ 'foo bar' =~ "<"foo">" ]]
And when you quote a character on the right-hand side of = or =~ inside
a [[ command, that character LOSES whatever specialness it might have
had in that context.
In order to put a backslash-that-acts-like-a-backslash-to-the-regex-engine
inside the RE on the right-hand side of =~ you need to put the RE into a
variable.
(Normally this is not a problem because normally you write POSIX
ERE-compliant regexes because that's all that you can count on, and POSIX
EREs don't use backslashes to turn features ON. Only to turn them OFF.)
> Empirically all this demonstrates:
>
> 1. bash recognizes \< \> \b as word anchors
Only on some systems. Not on others. So don't do that.
> 2. bash doesn't evaluate them correctly when used as literals
> 3. bash evaluates them correctly when used with parameter expansion
Which is one of the reasons it is STRONGLY encouraged to put your RE
into a variable and then use =~ $var.
(Another reason is backward compatibility with bash 3.x versions, should
you happen to care about that.)
Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~, Chet Ramey, 2018/07/10