From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <775b8d190801032331u69725293lc35b536f2fd3b9a4@mail.gmail.com>
Date: Fri,  4 Jan 2008 18:31:48 +1100
From: "Bruce Ellis" <bruce.ellis@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] frogs and osx
In-Reply-To: <E87A0939-AA5A-4D98-BB8F-871A59CF8F10@orthanc.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080104022953.CE1461E8C1F@holo.morphisms.net>
	<E87A0939-AA5A-4D98-BB8F-871A59CF8F10@orthanc.ca>
Topicbox-Message-UUID: 26f73ecc-ead3-11e9-9d60-3106f5b1d025

not at all, pragmatic.excluding crap from filenames was and still is good.
if you want to vote '\r' as "not a mistake"  you can.  but filenames created
from buggy stuff die dead, as they should.

brucee

On Jan 4, 2008 6:24 PM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
>
> On 2008-Jan-3, at 19:29 , Russ Cox wrote:
>
> > In addition to NUL, surely / should be illegal!
> > I certainly wouldn't want \n in file names; \r seems just too close.
>
> Pathological egregiousness?
>
> There is only one true separator, and that is '/'. In the context of
> pathnames, '/' is NUL as per C strings. NUL in pathnames is silly, but
> allowed, as per pathnames.
>
> It makes no sense, but if you can push a NUL into a pathname, you
> should deal with the result. It's a pity the intermediate code has to
> do so as well ...
>