On Thursday 28 May 2009 22:38, pk wrote:
> Yes, if the second argument is quoted, it's treated as a literal string.
> If you want the regex behavior, you should not quote it:
>
> if [[ "$Var" =~ +([:digit:]) ]]; then .
>
> That behavior changed at some point during 3.2 (too lazy to check now).
On Thursday 28 May 2009 21:58, Linda Walsh wrote:
> But when I used regex pattern matching in the if, the spaces around the
> operator
> caused a failure in matching. I.e.:
> if [[ "$Var"=~"+([:digit:])" ]] ; then ...
> worked.
"worked" in the sense that [[ .. ]] evaluated a single argument: the
On Thu, May 28, 2009 at 12:58:10PM -0700, Linda Walsh wrote:
> operator caused a failure in matching. I.e.:
> if [[ "$Var"=~"+([:digit:])" ]] ; then ...
> worked.
No, this is incorrect. You need spaces around the =~ so that it's parsed
as three separate things, rather than one thing. Your
Chet Ramey skrev:
Seved Torstendahl wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDO
Instead of checking if "$Var" was equal or not equal, I wanted to use
pattern matching.
Normally, for = or !=, I'd write:
if [[ "$Var" = "4" ]]; then ...
But when I used regex pattern matching in the if, the spaces around the operator
caused a failure in matching. I.e.:
if [[
Chris F.A. Johnson wrote:
> On Thu, 28 May 2009, Chet Ramey wrote:
>
>>> This is nothing new; it happens in all versions of bash:
>>>
>>> printf "Enter something: "
>>> read -e whatever
>>>
>>> Press a key, then cursor left (or ^A); the cursor moves to the
>>> beginning of the line, over "E" inste
On Thu, 28 May 2009, Pierre Gaston wrote:
> On Thu, May 28, 2009 at 3:52 PM, Chris F.A. Johnson
> wrote:
> > On Thu, 28 May 2009, Chet Ramey wrote:
> >
> >> >
> >> > This is nothing new; it happens in all versions of bash:
> >> >
> >> > printf "Enter something: "
> >> > read -e whatever
> >> >
>
Mitar wrote:
> Hi!
>
> I have found a discrepancy between documentation (man page) and
> behavior of Bash under -e switch. In documentation it is written:
>
> The shell does not exit if the command that fails is part of the
> command list immediately following a while or until keyword, part of
>
On Thu, May 28, 2009 at 3:52 PM, Chris F.A. Johnson wrote:
> On Thu, 28 May 2009, Chet Ramey wrote:
>
>> >
>> > This is nothing new; it happens in all versions of bash:
>> >
>> > printf "Enter something: "
>> > read -e whatever
>> >
>> > Press a key, then cursor left (or ^A); the cursor moves to t
On Thu, 28 May 2009, Chet Ramey wrote:
> >
> > This is nothing new; it happens in all versions of bash:
> >
> > printf "Enter something: "
> > read -e whatever
> >
> > Press a key, then cursor left (or ^A); the cursor moves to the
> > beginning of the line, over "E" instead of over the characte
>
> This is nothing new; it happens in all versions of bash:
>
> printf "Enter something: "
> read -e whatever
>
> Press a key, then cursor left (or ^A); the cursor moves to the
> beginning of the line, over "E" instead of over the character just
> entered.
This isn't a bug; that's where readli
Hi,
AFAICS from examples/loadables/ a lot of headers are readed
by the compiler which requires - beside the bash and the
readline library - an further package (rpm/deb) bash-devel
for including all those headers ... beside this the Makefiles
do not install any of them.
Therefore my question: how
12 matches
Mail list logo
