From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri,  5 Oct 2012 10:25:33 -0400
To: 9fans@9fans.net
Message-ID: <37362a64c5aa9018d47a5ba6f10fcba5@brasstown.quanstro.net>
In-Reply-To: <5945870.BeEu8mdyey@coil>
References: <1492275.224dsYbtlA@coil> <12158316.NY6jp8kkEc@coil>
	<c93703a07e40452787147e62b3525945@brasstown.quanstro.net>
	<5945870.BeEu8mdyey@coil>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] acme + plumber question
Topicbox-Message-UUID: bd481528-ead7-11e9-9d60-3106f5b1d025

> i've tried in two ways, both failed: data matches='foo
> ' (literal newline) and data matches='foo\n' (C-style escape sequence). first
> trips plumber's parser, the other doesn't match anything -- perhaps \n is
> taken literaly.

it looks like plumber's failure of vision.  regexps don't take escapes like that.
and on the other hand you can't say \ + literal newline, either.  plumber
misparses that.

however, i thought of a really sneaky cheat, that is almost correct.  since
\n is 0a, and we almost never see 09 or 0b (ht and vt), we could build a
sneaky character class to elude the parser:

data	matches	'error[	-]'
plumb	start	window

and i've verified this does work on plan 9.  a proper fix would be to
change the string parser in plumber to convert '\' + 'n' to a newline.

(but i do feel dirty.)

- erik