in reply to @ in regex, or not?

First, watch out for the 'dot' in your set, which Perl interprets as "stuff" (i.e. not a linefeed ('\n'), unless you're using crazy regexp options like /s). You probably mean literal-dot ('\.') instead.

Secondly, I'm not sure why you're using a negative match assertion ('!~') instead of a positive one ('=~'). It seems to be the opposite of what you're looking for:      if ($entry =~ /^([a-zA-Z0-9\@_\.]*)$/) { This code memorizes the entire e-mail address, which is apparently what you intended by using the brackets in your regexp. As a note, though, since you are memorizing the entire thing, why bother to do this instead of just using $entry?

Note: On the subject of e-mail address matching regexps, you will have to be more open-minded about what can appear in these. For example, many characters other than the ones you specified are actually valid in the e-mail address part of the name. I would modify it so that the checks on the e-mail address part are more liberal, and further, that instead of using the star operator (0 or more), which has the unfortunate effect of validating a zero-length string(!), that I would demand at least one character on each side.     if ($entry =~ /^([a-zA-Z0-9_\.\-\!\%\#]+\@[a-zA-Z0-9_\.]+)$/) { Here's some e-mail addresses which could be used to test any modifications:
qw [ abc@123.it a@b tech-support@super.net user_144@z.com webmaster@estherdyson.museum ];
Tip: It is probably a good practice to "escape" all non-alphanumeric characters in your regexps until you know which ones are safe. As you found out, a seemingly inert '@' was interpreted otherwise, and the unassuming '.' means a whole lot more than just dot inside a regexp.

Replies are listed 'Best First'.
Re: Re: @ in regex, or not?
by arturo (Vicar) on Mar 26, 2001 at 21:19 UTC

    Important correction: outside of a character class, . means "match anything" (except a newline, unless told otherwise), but inside a character class, it DOES mean a literal dot.

    Philosophy can be made out of anything. Or less -- Jerry A. Fodor

      Strange but true. It is odd, though, that '@' is parsed in there as meaning array, but the previously all-powerful '.' reverts back to meaning just a dot. Like Kryptonite does to Superman?
        More fun with Deparse and the all too fleeting concept of special characters, giving further evidence that our character set is perhaps just not rich enough for Perl's liking ;-):
        === 1 === perl -MO=Deparse -e "$_='abc@de';print if(/[_@]/)" $_ = 'abc@de'; print $_ if /[_\@]/; -e syntax OK perl -e "$_='abc@de';print if(/[_@]/)" abc@de === 2 === perl -MO=Deparse -e "$_='abc@de';print if(/[@_]/)" $_ = 'abc@de'; print $_ if /[@_]/; -e syntax OK perl -e "$_='abc@de';print if(/[@_]/)" /[]/: unmatched [] in regexp at -e line 1. === 3 === perl -MO=Deparse -e "$_='abc@de';print if(/[_@a]/)" In string, @a now must be written as \@a at -e line 1, near "[_@a" -e had compilation errors. $_ = 'abc@de'; print $_ if /[_@a]/; === 4 === perl -e "@a[0]='z';@a[23]='oob';$_='abc@de';print if(/[_@a]/)" abc@de
        My guess: In the first example, Perl has escaped the @ itself since it saw no array there, but in the second example, it saw an array, and accepted the syntax, but in evaluation it vanished. In the third case, Perl knows there is no @a array and barfs, telling be to be more specific, however if @a does exist (example 4), Perl proceeds, though perhaps not doing what the author intended - it concatenates all the elements of @a and matches against the resulting string (that I didn't expect).

        Usually when I play around like this I learn something interesting, but as often as not I also end up with new questions!

        --
        I'd like to be able to assign to an luser