World: r3wp

yes ,  my rule was for a single lin as in your first code  sample

is ^J the line feed ?

copy header ti ["^J^J" | "^M^M" | "^M^J^M^J"]

^J same as ^/

>> header-rule: [copy header thru ["^J^J" | "^M^M" | "^M^J^M^J"] 
 (write-client header)]
== [copy header thru ["^/^/" | "^M^M" | {^M
^M
}] (write-client header)]
>> parse m header-rule
** Script Error: Invalid argument:

 |


** Near: parse m header-rule

try {^M^/^M^/}

not that it shoulf matter

same problem

it is interperting the third newline ... odd  buggy odd

parse all?

os use |  2 CRLF

>> unix: [ copy header thru "^J^J" ]
== [copy header thru "^/^/"]
>> msdos: [ copy header thru "^/^/" ]
== [copy header thru "^/^/"]
>> parse m [ [ unix | msdos ] ( write-client header ) ]

ms dos  not correct

is that correct rule for unix ?

yes

what's msdos ?

mac ^M^M  dod ^M^J unix ^J

mac is a single ^M for a single line

[2 "^/" | 2 "^M" | 2 CLRF]

>> parse m [ [2 "^/" | 2 "^M" | 2 crlf ] ( write-client header ) 
]
== false

dos is : join crlf crlf .. isn't it ?

... copy haader theu ...

parse m [ copy header thru [2 "^/" | 2 "^M" | 2 crlf ] ( write-client 
header ) ]
** Script Error: Invalid argument: 2
 | 2 crlf

copy header [thru 2 "^/" | thru 1 "^M" | thru 2 crlf]

it annoys me the to/thru does not distribure over the block of ORs

me too ...

off to the coast for the weekend, got to pack

ok.

This rule seems to now work for me ...


  header-rule:  [ [ copy header thru {^M^J^M^J} | copy header thru 
  {^/^/} ] (write-client header )]

not sure if the second rule is needed ...

;I tend to use charsets as a way of skipping 'thru while looking 
for multiple possibilities:
line-end: charset [#"^/" #"^M"] ; etc
line: complement newlines

parse m [copy header [some [some line line-end]]]

a way of skipping
 -> "an alternative to"

is it faster?

It's hard to compare when 'thru doesn't fork.

or is it slower ?

For what it's worth, my benchmarks show it to be quick, but my benchmarks 
tend to be crude...

line: complement line-end

That means any character that isn't a line-ending...

yes, you have comlement newlines

Sorry, changing names as I go :o)

line-end: charset [#"^/" #"^M" #"^J"]
line: complement line-end
parse m [copy header [some [some line line-end]] to end]

; Note that 'line-end in the parse line should be replaced with permutations 
of what a line-ending can be, without describing any permutation 
of a double line-ending.

Graham,  I'd probably use parse/all rather than parse. Also don't 
forget the parse-header function and all the associated bug fixing 
work related to it in view 1.3 project. May or may not be of use 
to you.

I don't think you need to distribute the thru. eg:

parse "..abab..." [".." copy header ["aa" | "bb" | "abab"] (?? header) 
to end]
header: "abab"
== true

I'll give this one a go as well.

But I wanted the line endings in the "header" variable as I send 
it on to the client.

The second line is the print out from (?? header)

Joe:   What do you need a perl comatible regular expression  to do?

He could hand it off to developers that are familiar with pcre but 
not parse, for starters.

It wouldn't have to be industrial-strength, but it would like a security 
blanket for developers experimenting with the new language. PCRE 
is found all over the place in languages on Linux machines, and the 
absence makes some developers uncomfortable - despite the fact that 
Parse is better.