simple regular expression

[Olaf]

Which is the simplest way to know if a $var start and finish with the
same character?

 

[John W. Krahn]

Which is the simplest way to know if a $var start and finish with the
same character?

$var =~ /\A(.).*\1\z/s;


John

 

[Olaf]

$var =~ /\A(.).*\1\z/s;

Ok, but I don't understand. I need to learn more about regular exp.
I suppose that the answer would be possible, comparing first and last
with ^ and $.

 

[Olaf]

$var=<STDIN>; chomp($var); if (($var =~ /^./) = ($var =~ /.$/ )) {}

 

[John W. Krahn]

$var=<STDIN>; chomp($var); if (($var =~ /^./) = ($var =~ /.$/ )) {}

$ perl -ce'$var=<STDIN>; chomp($var); if (($var =~ /^./) = ($var =~ /.$/ )) {}'
Can't modify pattern match (m//) in list assignment at -e line 1, near ")) "
-e had compilation errors.

Perhaps you meant:

if ( substr( $var, -1 ) eq substr( $var, 0, 1 ) ) {}



John

 

[Dr.Ruud]

Olaf schreef:

John W. Krahn:

[head eq tail]
$var =~ /\A(.).*\1\z/s;

Ok, but I don't understand. I need to learn more about regular exp.
I suppose that the answer would be possible, comparing first and last
with ^ and $.

Read perlretut and perlre.
Hint-1: If your $var can contain newlines, you need to use "\A" in stead
of "^".
Hint-2: See the s-modifier.


Alternative, using "^" and "$" anchors:

$c = qr/.|\n/ ;
$var =~ /^($c)$c*\1$/ ;

Alternative for $c:

$c = qr/./s ;

 

[Mirco Wahab]

$var=<STDIN>; chomp($var); if (($var =~ /^./) = ($var =~ /.$/ )) {}

The closest thing to your trial would be
probably sth. like this (as others have already said):

chomp( my $var=<STDIN> );

if( $var =~ /^(.).*?\1$/ ) {
print "thats it\n"
}
else {
print "nope\n"
}


JWK already posted a more general solution
with "\A ... \z" as the string boundaries, you
can - in many cases (find out wich) use the "^...$"
notation that you tried to apply above.

What you really search after is therefore:

^(.) ==> start of line with one character following
==> capture this charachter as #1
..*? ==> find any (0 or more) characters until (?)
\1 ==> ... the first captured character shows up
$ ==> directly followed by a 'line end'


You could also find a solution (besides the substr thing)
by stating

...
chomp( my $var=<STDIN> );
print map{ $_->[0] eq $_->[-1] ? 'same':'differ'} [split '', $var];
...

Regards

Mirco

 

[John W. Krahn]

Olaf schreef:

John W. Krahn:

[head eq tail]
$var =~ /\A(.).*\1\z/s;

Ok, but I don't understand. I need to learn more about regular exp.
I suppose that the answer would be possible, comparing first and last
with ^ and $.

Read perlretut and perlre.
Hint-1: If your $var can contain newlines, you need to use "\A" in stead
of "^".

Without the /m modifier \A and ^ are exactly the same.


John

 

[Dr.Ruud]

John W. Krahn schreef:

Dr.Ruud:

Olaf:

John W. Krahn:
[head eq tail]
$var =~ /\A(.).*\1\z/s;

Ok, but I don't understand. I need to learn more about regular exp.
I suppose that the answer would be possible, comparing first and
last with ^ and $.

Read perlretut and perlre.
Hint-1: If your $var can contain newlines, you need to use "\A" in
stead of "^".

Without the /m modifier \A and ^ are exactly the same.

Aaargh, thanks for the correction.

The /s modifier makes "." also match a newline.
The /m modifier makes "^"/"$" match start/end of any embedded line.

 

[Arved Sandstrom]

John W. Krahn ([email protected]) wrote on MMMMDCCCXVI September
MCMXCIII in <URL:`` Olaf wrote:
`` > Which is the simplest way to know if a $var start and finish with the
`` > same character?
``
`` $var =~ /\A(.).*\1\z/s;


That would not match if $var equals "a". Which, IMO, starts and finishes
with the same character.

If you were going to do this with a regexp, I'd use:

$var =~ /^(?=(.)).*\1\z/s;


But I'd rather do:

length ($var) && substr ($var, 0, 1) eq substr ($var, -1, 1);

I also would rather do the latter. It is faster (by about a factor of two on
my machine). But more importantly, it's simply more clear than the RE. Not
by much - it's a simple RE - but clearer nevertheless.

There's a time and a place for regular expressions. But the string functions
exist for a reason and sometimes they're better.

AHS

 

[Ted Zlatanov]

There's a time and a place for regular expressions. But the string
functions exist for a reason and sometimes they're better.

Are there any cases (within the scope of intended usage--fixed offsets
and search strings) that index, length, and substr are slower than
regular expressions? I don't know of any, and I'm curious.

Ted

 

[Uri Guttman]

TZ> Are there any cases (within the scope of intended usage--fixed
TZ> offsets and search strings) that index, length, and substr are
TZ> slower than regular expressions? I don't know of any, and I'm
TZ> curious.

in general any single call to the simpler string funcs should be faster
than an equivilent regex call. i agree it would be hard to show a
concrete example that contradicts that and i bet if one does exist it
will be a very degenerate example. but combining several simple string
calls in an expression could very well be slower than the equivilent
regex. the rule of thumb (and perl is very thumbish is that the more
perl code you run the slower vs the more c (perl guts) you run the
faster. but that rule can quickly be broken by the classic s/^\s+|\s+$/g
being slower than that split into two s/// calls.

uri

 

[Peter J. Holzer]

Are there any cases (within the scope of intended usage--fixed offsets
and search strings) that index, length, and substr are slower than
regular expressions? I don't know of any, and I'm curious.

Note that he wrote "better", not "faster". "Better" in code is usually a
mixture of several aspects and readability and maintainability are often
considered more important than performance.

hp

 

[Ted Zlatanov]

Note that he wrote "better", not "faster". "Better" in code is usually a
mixture of several aspects and readability and maintainability are often
considered more important than performance.

I think speed is the only aspect of code that everyone can agree on.

Ted

 

[Tad McClellan]

I think speed is the only aspect of code that everyone can agree on.

Not if they happen to have different data...