World: r3wp

so, it's to prevent incoming data being executed ?

you can write a well considered script without taint that is far 
more secure than a script that passes taint mode by making a simple 
rule that does not properly catch  problems

you basicky have to weite a regular expression to accept user input

Graham: for your header, like Brett said, parse/all is needed when 
you work on strings with newlines and spaces. last line should be:
parse/all header [header-rule some [ thru "^/" header-rule]]

Graham, yes, but it's also used in other situations: force the programmer 
to escape HTML input before printing it back out, massaging data 
so that it's friendlier for the database, etc.

Yeah, I got that Vincent.  Curiously though it has worked without 
it.

in your example  having a rule more like 
header-rule: [
    "Date:" copy date-rule  |
    "From:" copy email-rule |
    "Subject:" copy some alpha-num  |
    "To:" copy email-rule |
    to newline
]

where email-rule only matched email addresses  
 would more taint like

and being very careful to never  effectivly 

do [ user-input]


without being sure user-input  could not cause unintended side effectd

Not quite sure what to make of the following:
>> rule: [set w 'pubDate (print w)]
== [set w 'pubDate (print w)]
>> parse [pubdate] rule
pubdate
== true
>> parse/case [pubdate] rule
pubdate
== true

First off, would the last result be a bug?

Secondly, I'd like to ensure that whether the block is [pubdate] 
or [pubDate] that 'w stores 'pubDate.  I had hoped that as 'pubDate 
is set in the rule, it might take precedence over pubdate in the 
block :^(

I suppose /case only act on string!

/case only applies to strings. Chris, you can:

>> parse [pubdate] ['pubDate (w: 'pubDate print w)]
pubDate
== true

but i'm not sure you'll like it.

should be something easier than this 

like-i: charset [ #"1" #"l" #"L" #"I" #"i" ]
like-a: charset [ #"a" #"A" #"@"  ]
like-v: charset [ #"\" #"/" #"v" #"V" ]


cialis: [ "c" like-i like-a 2 like-i "s" ]
viagra: [ 1 2 like-v like-i like-a "gr" like-a ]

parse "\/[1-:-gr]@" [ viagra ]
parse "[c1-:-Lls]" [ cialis ]

hmm.. altme converts my double quote to a single quote

maybe use   charset "1lLIi"    to avoid that much typing ;)

Graham, the link width is slightly incorrect, so it obscures half 
of the double quote, so it looks like a single.

flatten: func [b [block!] /local flat][
	flat: copy[]
	rule: [
		some[
			[x: block! (parse first :x rule)] |
			[copy token any-type! (append flat token)]
		]
	]
	parse b rule
	flat
]

without the recursive call to parse

flatten: func [b [block!] /local flat rule x][
	flat: copy[]

 rule: [some[[x: block! :x into rule] | [copy token any-type! (append 
 flat token)]]]
	parse b rule
	flat
]

a flatten  that changed it's block in place would be useful at times

Something like this? (it's not parse based though)

    flatten: func [block] [
        head forall block [
            if block? block/1 [change/part block block/1 1]
        ]
    ]

I have a problem with parse not terminating the parsing. Here is 
my code for parsing CamelCase words:

rebol []

; CamelCase Test


test-text: "FirstWord test. This is a CamelCase test Text. CamelCase2 
is the base idea for a WiKi. CamelcasE"

upper-case: charset "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
delimiters:	charset " .,;|^-^/"
rest-chars: complement union upper-case delimiters

text: ""

parse/all/case test-text [
	some [

   copy camelcase-word [upper-case some rest-chars upper-case any rest-chars] 
   (
		 	if not empty? text [?? text clear text]
		 	print ["CamelCase word found:" camelcase-word]
		)

  | copy flowtext [any [rest-chars | upper-case] any delimiters] (
			append text flowtext
		)
	]
]

halt

Any idea why parse doesn't return?

[any [rest-chars | upper-case] any delimiters] is always true, even 
if there is no char left  at the end. But it does not move the cursor.

rebol []

; CamelCase Test


test-text: "FirstWord test. This is a CamelCase test Text. CamelCase2 
is the base idea for a WiKi. CamelcasE"

upper-case: charset "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
delimiter:	charset " .,;|^-^/"
rest-char: complement union upper-case delimiter

text: copy ""


camelcase-rule: [some [upper-case some rest-char upper-case any rest-char] 
delimiter]

parse/all/case test-text[
	some [ 
			copy camelcase-word  camelcase-rule
				(if not empty? text [?? text clear text]
		 		print ["CamelCase word found: " camelcase-word]
				)
			| 
			copy flowtext upper-case 
				(append text flowtext)
			|
			copy flowtext[any [rest-char | delimiter]] 
				(append text flowtext)
	]
]
halt

what about camelCAse?

Personally I prefer the way mediawiki does it ... using [[ .. ]] 
... instead of having strange cases in words

yes, I was also concerned about  A1CamelCase  but figured Robert 
 just needed to get thru his first question first

Thanks, for the fix. Sometimes it helps to get some distance by asking 
others :-))

I like CamelCase words. Simple to remember and use. IIRC camelCAse 
is not a valid CamelCase word. But anyway, it depends how I teach 
my users :-))

http://en.wikipedia.org/wiki/CamelCase... CamelCase is referred 
to UpperCamelCase, and camelCase is referred to as lowerCamelCase

Tom, your example doesn't terminate, like mine. The thing IMO is 
that the last Word is a CamelCase word and the 'end condition is 
somehow missed. It nevery reaches the halt.

If you do not want to change the parse rules, you can just add
	if not flowtext [halt]
before
	append text flowtext

I can change the parse rules. This is just a test script, the rule 
needs to be included in a broader parsing engine. So, it must return 
TRUE.

Robet you also have to worry about  YaBaDaBaDoCamelCases  (even and 
odd) 

to get it to return true ,  figure out what is left when the outter 
most  some finishes.
parse ...[
	some [
		...
	]
	copy remenant to end ( print remenant)
]


then make  the  your rule cpnsume the remenant ok if you  don't care 
just put a  
	to end
there

You can either put your parse in a catch [] and throw a true if not 
flowtext 
or something like this
parse/all/case test-text [
	some [

   copy camelcase-word [upper-case some rest-chars upper-case any rest-chars] 
   (
		 	if not empty? text [?? text clear text]
		 	print ["CamelCase word found:" camelcase-word]
		)

  | copy flowtext [some [rest-chars | upper-case] any delimiters] (
			append text flowtext
		)
		| copy flowtext [some delimiters] (
			append text flowtext
		)
	] to end
]

addendum/corrected
	] to end (if not empty? text [?? text])

getting the following error  when running Didec's delete email script 
against a mailbox with large number of emails (250+):internal limit 
reached: parse
Near: [parse data maillist
   addr-list]
Where: parse-mail-list

is this a rebol internal limit of should i start debugging?

probably a parse limitation

I think I've opened up mailboxes with over 400 emails before using 
Cerebrus' mailbox manager with no problems

oh well. thanks :)

what you could do, is extract Didier's implementation of the TOP 
command, and then get the first line of each header in your mailbox. 
 If it has the return-path set to <>, then note it in a list.  When 
finished, go thru and issue deletes on all of those.

thanks! I'll have a look at that.

is the To: line very, very long? there's a recursion limit in the 
parser for the address list. since you are probably not interested 
in parsing the To: header, maybe you can disable it in import-email.

Hmm... my parse still not termines the 'some part. I never reach 
the end. The problem is that the rest of the string is "" and this 
seems not to be handled.

Ok, got it. Now it works.