From mboxrd@z Thu Jan  1 00:00:00 1970
From: 9p-st@imu.li
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
In-Reply-To: <20130502193952.GA662@polynum.com>
References: <20130502123825.GA1975@polynum.com><20130502150829.GA435@polynum.com><d8aecdc9b2e88ca91a3730e70e1fef1c@ladd.quanstro.net><2292951.aK3zqF2TmN@blitz>
	<20130502190415.GB412@polynum.com><4a14b1c442389a52b89aad17acbb615e@ladd.quanstro.net>
	<20130502193952.GA662@polynum.com>
Message-Id: <257b5f.5863bd23.PHUY.mx@tumtum.plumbweb.net>
Date: Thu,  2 May 2013 16:17:11 -0400
User-Agent: mx
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] Octets regexp
Topicbox-Message-UUID: 520bc3e4-ead8-11e9-9d60-3106f5b1d025

> On Thu, May 02, 2013 at 03:22:21PM -0400, erik quanstrom wrote:
> > can you give an example of xd outputting something that's not a rune?

if we're talking about xd, i'll suggest 'tcs -f 8859-1' again in which ca=
se:

> Indeed, if the regexp is an ASCII representation matching xd outputs
> there is not _this_ problem. But this is limited regexp, since one can
> not use "character" ranges (it depends on the size); not '.';

these problems go away

> because the conversion has to be done;

this remains

> because there is still the newline problem (that is added; not somethin=
g in
> the original data) (if functions have been added to not deal with the
> newline, it is because the newline is a problem, and because regexp hav=
e a
> more wider use than "text").

and this problem goes away.

i imagine you'll still have problems with embedded NULs, but that's C
strings for you...

if you want a library function, use rregexec(2) and rregsub(2) with only
the low byte of each Rune filled...

(and yes, your data does quadruple itself)

tristan

--=20
All original matter is hereby placed immediately under the public domain.