some clarification is in order.

At 08:00 PM 1/19/00 -0800, [EMAIL PROTECTED] wrote:
>This solution doesn't use regular expressions or parsing. But it's far
>easier to see what the intent of the code is. Parsing is my second
>solution...
>    I did it this way, because the (^) caret[?sp] in REBOL strings is the
>escape character for encoding special characters in strings. Note that the
>"^" disappears from bobr's original code:

oops! 

>>> userlist
>== {(ted|admin|bobr|andrew|elan|keith|cheryl|joel|brady)$}
>
>
>>> User_List: ["ted" "admin" "bobr" "andrew" "elan" "keith" "cheryl" "joel"
>"brady"]
>== ["ted" "admin" "bobr" "andrew" "elan" "keith" "cheryl" "joel" "brady"]
>>> Current_User: "bobr"


to go from 
 ^(ted|admin|bobr|andrew|elan|keith|cheryl|joel|brady)$
which is what is literally in the input stream/file to 
  ["ted" "admin" "bobr" "andrew" "elan" "keith" "cheryl" "joel" "brady"]
needs to be explained. the rest using 'find is trivial.
 (though you don't cover excluded values or prefixes or suffixes)

I too saw that ^ was special and tried to use {} to hint that the buffer
contents were to be taken literally. my apologies.
I guess we could strip them [ ^ and $ ]
but I would still need to go from (a|b) form to ["a" "b" ] form.

I do have alt2600 cracker types who will try:

^(bobr|me" halt "pi|andrew)$

just to pull my goatee with a denial of service attack.
reading ahead there is even worse stuff with

^(bobr|me"hum"m^(q)|andrew)$

to be dealt with. [on mozilla the 'kids' do try and pick
perverse names knowing the database will copy them about]



 
>A similar procedure will work for file names as well.

it is not important that the names are files,
they could as easily be record identifiers in a database.
what is critical is that it is a list of prefixes
to be excluded from selection.

the other important thing is that the list is coming
from a stream or string buffer.  IE something
that was typed in by a human. it is not a compiled
rebol expression unless you show me
the lines that compile/eval it.

these simplified re's
constitute a special purpose dialect
used to describe something well 
known to an existing group of people.

you were correct in using 'ask to pick it up
as that pretty closely resembles a stream.



 
>Or for another approach, using 'parse:
>
>>> userlist: ask "Please enter users: "
>Please enter users: ^(ted|admin|bobr|andrew|elan|keith|cheryl|joel|brady)$
>== {^^(ted|admin|bobr|andrew|elan|keith|cheryl|joel|brady)$}
>
>Users: make object! [
> Names: make block! 10
> Name: make string! 30
> Name_Rule: [
>  copy Name [to "|" | to ")"] (append Names Name) [thru "|" | thru ")"]
>  ]
> Parse_Names: func [Simple_RegExp [string!]] [
>  clear Names clear Name
>  parse/all Simple_RegExp ["^^(" some Name_Rule thru "$" to end]
>  ]
> ]
>


'parse used above comes close but
does this solution handle negated match expressions?
prefixes? suffixes?

maybe if I exposed more context
to where these are used it would help.



here is the perl code I was trying to replace.

sub userInList { my ($user, $userlist) = @_;
  $user =~ s/$userlist//;  # a perfect match erases all chars
  return ( $user eq "" ) ? 1 : 0;
}

I realize this perl is compact.
I know it won't do prefixes. normally, $userlist contains 

^(ted|admin|bobr|andrew|elan|keith|cheryl|joel|brady)$

we are not permitted to change the syntax to a "block" form
because we want to show off that rebol can seamlessly
displace the perl and not require users (non programmers)
of the app to learn new syntax (dialect) just because
implementation language changed.

replacement of the syntax would mean changing the strings
in thousands of data records. too much work.
we can change local copies but that is it.


the other case for the file prefixing and suffixing was
this (simplified) perl snippet:

sub filesList {
    local( $pat, $sortage, $foo) = @_;

    opendir(DIR,"$textLocation/$wdb");
    @filesset = grep( /$pat/ && !/^\./ && /$txt/, readdir(DIR));
    closedir(DIR);
    $foo = "%" . join("% <br> %", @filesset) . "%";
    if ( $foo eq "%%" ) {
        return "";
        }
    $foo =~ s@:@/@g;
    if ( $sortage eq "" ) {
        $foo =~ s/$txt%/%/g;
        return $foo;
        }
    ...

it is rife with all kinds of accreted violations of pure/ideal code.
it is an example of what the dirty real world is
running on and a chunk of code I must eventually displace.
I am appealing to the list because if I do it
will balloon up to hundreds of special cased lines
and take a long time.
I think you cats can knick the bloatware element.

FYI: if you want to try and code up the
whole function here is its 'spec' for the above snip.

the variables brought-in from external scope are:
 $txt - file type suffix like \.gz, \.jpg, \.html but not limited to
 $wdb - database dir or image-file-dir
 $textLocation - root of all data files for this app instance

the function is (usually) called with one of those simple REs
to be used to match files.

$ans = filesList("^(?!(notxt|ask_new|only_owner_may_edit))", "");

and no, the args aren't compiled literals like you see,
they too are read from other data records.

$sortage (for extra credit) is used to indicate
sort by date/by size, etc.

what must be returned is a list of file names
with : replaced by / and
with each wrapped in %chars% and 
a <br> separating each one.
leading dotfiles quietly go away.


{-----}
[EMAIL PROTECTED]

Reply via email to