in reply to Re^2: how should i test whether a string contains between 6 and 20 letters and numbers
in thread how should i test whether a string contains between 6 and 20 letters and numbers

My sample code (the solution is actually the regex /^[a-zA-Z0-9]{6,20}$/) removes trailing line seperators (however they may currently be defined). A blank line will comprise two consecutive line seperators and will result in an invalid string being detected - which is consistent with OP's criteria (and original code).

Note that at least part of the rationale for posting a "complete sample" is to show others with a technique for providing stand alone code to demonstrate a problem or solution. The line handling code is incedental to the OP's question, but is an important part of a technique for providing test data.

Hmm, ok I'll go get that coffee now :)


DWIM is Perl's answer to Gödel
  • Comment on Re^3: how should i test whether a string contains between 6 and 20 letters and numbers
  • Download Code

Replies are listed 'Best First'.
Re^4: how should i test whether a string contains between 6 and 20 letters and numbers
by brian_d_foy (Abbot) on Jan 30, 2006 at 01:20 UTC

    Actually, a blank line has only one line separator (like any other line). It just happens it doesn't have anything before it. Your solution removes a single line separator: take a look at the docs for chomp again-you have to be in paragraph mode to remove all trailing newlines. There's nothing to say that there might be more than one of those. That your solution is consistent with the OP's similarly broken code is little consolation.

    Your solution misses because you make assumptions about the input, and those aren't warranted. You can fix that with \z, which makes the regex do exactly what the poster wanted and takes so little effort, and best of all, doesn't assume anything else about the provenance of the input. Are you arguing against something that absolutely solves the problem over something that might not when the clever cracker or ill designed program tries to get around it?

    C'mon, the fix is simple. Just use it and be right. :)

    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review

      I must be being particuarly dense today because I just don't understand where you are coming from with this!

      Consider the following two variants of the code I posted:

      Given: __DATA__ Success Invalid string! ... { if (/^[a-zA-Z0-9]{6,20}\z/) { ... prints: Invalid string: >Success < Invalid string: > < Invalid string: >Invalid string! < and ... { chomp; if (/^[a-zA-Z0-9]{6,20}\z/) { ... prints: Success: >Success< Invalid string: >< Invalid string: >Invalid string!<

      Where is the problem? At the end of the day both variants tag the invalid strings invalid and the valid string valid. For the sample code the \z variant with no chomp prints the line end characters from the input data - but that was not important to the sample code, in fact it is distracting.

      We have no information about why OP needs this code (although validating passwords does seem likely) and it's not clear to me what assumptions I am making that would cause a clever cracker to continue his career. Would you care to sketch a scenario showing how the solution is substandard?


      DWIM is Perl's answer to Gödel

        The problem is that we have no idea where the data is coming from, but your solution constrains it to reading from the DATA filehandle. Your solution only works for those cases. If the string comes from a different source that doesn't process things by lines then your regular expression fails. It only works because you constrain the source of input. However, by making my simple change, you don't have to care about that. I've already shown you a string that broke your solution. Take any of the other infinite number of ways to get data inside a scalar and you'll have your example.

        Why fight it? If you only want a-zA-Z0-9 in the string, why use a regular expression that would allow something else?

        --
        brian d foy <brian@stonehenge.com>
        Subscribe to The Perl Review