Re: [tlug] Re: tlug] Security question with grep/e...

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Tim" == Tim Hurman <kano-tlug@example.com> writes:

    Tim> Would it not be easier just to do this in PERL anyway, here
    Tim> is my reasoning,

No.  For most sane people (and Jim is one such), working with Perl
involves bowing to the Porcelain God.

Case in point:

    Tim>     die unless ($user_str =~ m/^[\w.]+$/);

With the single exception of "\]", backslash escapes in a character
class are an abomination.  (Here you should of course use my title
when citing; this is a purely personal opinion and therefore needs all
the authority it can muster to become established as Received Truth.)

Not to mention that if I grok his post correctly, Jim is working with
multilingual files, and the definition of "file character set" and the
various character classes is up for grabs.  In Jim's case, it's no big
deal.  But relying on Perl to get this stuff right is going to cost
you some day.  Multilingual text is hard, and POSIX didn't even try to
deal with it (Perl has extensions, but it's based on the POSIX model).

BTW, Martin asked what the Python idiom for "die unless" is.  It's

if not CONDITION: raise UncatchableError

The Perl is more expressive, but I prefer programs that are robust to
pilot error and even offer sensible advice:

try:
    # using try here allows for multiple error conditions to be
    # handled in a relatively clear way, and also allows you to throw
    # to the handler from a subroutine; for this example it's a gilt
    # lily, of course
    if not CONDITION (foo):
        raise CONDITIONError

    # code protected from failures of CONDITION here

except CONDITIONError:
    print "Your condition (%s) was bar; try bazing the quux." \
          % (foo)

continue_sensibly ()

One thing that's nice about Python (and Perl too) compared to (say) C
is that _printf is part of the language standard_ and therefore the
translator can check types for printf escapes.  The C standards people
(somewhat pedantically in these late days, but correctly IMHO) take
the position that the C standard does _not_ include the standard C
library, and therefore C compilers can't assume that printf is printf.

This is why the "<<" and ">>" I/O operators of C++ are a big deal, and
not just syntactic boogers: because they are operators, the types they
can handle are available to the compiler, unlike printf where the
operators are buried in a string.

Python uses the same strategy (Python 2.x still has printf but it's
considered unPythonic).  If the LHS of the % operator is a string,
it's actually not a string, but a subclass: a printf format spec.

OO ru237.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.