From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <356360bf0b6124fb81bee23d3829d62e@plan9.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] blanks in file names
From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-xqhphclwviplqtkjolhxekojmp"
Date: Thu,  4 Jul 2002 11:50:47 +0200
Topicbox-Message-UUID: c19b387e-eaca-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-xqhphclwviplqtkjolhxekojmp
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

So we need an uniform set of conventions, and make all the programs
obey them. And that's not the case right now. That's all I was saying
regarding %q.

thanks



--upas-xqhphclwviplqtkjolhxekojmp
Content-Type: message/rfc822
Content-Disposition: inline

Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Thu Jul  4 11:42:16 MDT 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 9A6BC199B7; Thu,  4 Jul 2002 05:42:07 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from lavoro.home.cs.york.ac.uk (public1-york1-5-cust17.leed.broadband.ntl.com [80.0.45.17])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 966341998C
	for <9fans@cse.psu.edu>; Thu,  4 Jul 2002 05:41:19 -0400 (EDT)
Message-ID: <30a861a9c8a7a63c0e69d46049d70908@caldo.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] blanks in file names
From: forsyth@caldo.demon.co.uk
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Thu, 4 Jul 2002 10:41:48 +0100

>>Is there agreement on this? Or is something else I'm also missing?

not exactly.  i think there's an implication though about the uniform
implementation of quoting rules throughout the system so that
	read(filename)
	open(dirname + "/" + filename)
would work because `filename' and `dirname' etc haven't any quotes,
because lines read from standard input (say) have been parsed.
some programs do so already but the conventions vary from place to place.
essentially, strings inside programs are in their parsed form and
strings read and written by a program are expected to be suitably quoted.
thus
	ls | mumble
would work because mumble will apply the standard rules (might be as simple
as calling tokenize consistently) to each line of its input, and thus unquote it
to reveal the original file names.

i say it's not just file names particularly; for instance, input to a program might
be fields
	when where howmuch why who
allowing
	15/9/1660 London 4d 'First Cup of Tea' 'Saml Pepys'
and with suitable changes comm, sort, etc. could be applied in obvious ways.

--upas-xqhphclwviplqtkjolhxekojmp--