From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id B5F7E2399B
	for <ml@inbox.vuxu.org>; Thu,  7 Nov 2024 09:47:49 +0100 (CET)
Received: from asquith.prosimetrum.com ([125.236.209.157]) by 9front; Thu Nov  7 03:46:40 -0500 2024
Message-ID: <8DF479DCD404E657DA8A64B2232A9BF7@prosimetrum.com>
Date: Thu, 07 Nov 2024 21:46:41 +1300
From: umbraticus@prosimetrum.com
To: 9front@9front.org
In-Reply-To: <CAFSF3XNvnQ5_QOS_mb4V90hnUXH-Y2pMM7m9zDOnD83iC6fLKg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: factory STM JSON table markup 
Subject: Re: [9front] plumbing with spaces
Reply-To: 9front@9front.org
Precedence: bulk

> "sadly the newline messes things up"
> which step actually messes it up? i realize only now that i never
> understood how this works.

Same. Thinking about it a bit, I'd say it probably has to do with
the regexps used in plumb rules: \n does not match a newline,
nor can you embed a literal one due to how the rules file is parsed.

e.g. sam & sed both mention something along these lines in their
respective manpages; here's sam(1):

	Regular expressions are as in regexp(6) with the addition of
	\n to represent newlines.

So to allow newlines in plumb "matches" rules those programs could
be a place to look. (or else make this a standard feature of regexp??)

umbraticus