From mboxrd@z Thu Jan  1 00:00:00 1970
From: anothy@cosym.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] blanks in file names
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20020711020105.C82D119A63@mail.cse.psu.edu>
Date: Wed, 10 Jul 2002 21:41:17 -0400
Topicbox-Message-UUID: c8c162b8-eaca-11e9-9e20-41e7f4b1d025

on the "linked lists for paths instead of strings with /" topic:
while i can see how this could be interesting to persue, from a
systems architecture research point of view, i'm unclear on how
exactly this helps us solve any of the problems people are
talking about. maybe i'm just missing something; if so, please
clue me in. but here's what i don't see:

first, it seems your suggestion is primarialy aimed at allowing
"/" in file names (perhaps some argument about generality or
interoperation with DOS-derived systems and "\" could be made,
as well). okay, i can see the theoretical benefit there (but it
strikes me as a much more dubious gain than spaces in file
names). but what would this system _look_ like, from a user's
point of view? what would the output of `pwd' be? a list of
strings? but how can i store a representation of that? wouldn't
that involve lots of interaction with the shell, or whatever
else was doing the interpretation (like $path does, although
that's used is very few places, and is very function-specific,
so isn't really much of an issue)?

second, i'm just not seeing at all how this helps us address
spaces in file names (and maybe it wasn't meant to; this
thread has wandered a bit). the dificult part of the problem
(perhaps the entirety of the problem) seems to lie in getting
the various tools that need to communicate to understand the
edges of file names: things like "grep `{ls} foo". i fail to
see how any of the kernel changes (or library additions) you
propose even talk to this realm of problem.

third: want newline too?

on another embedded thread, you wrote:
// You can do a lot of things if you're prepared to get
// involved in the functions that your OS should be doing
// automatically.  Try running an FTP mirror to a busy site
// that way, though, and you'll quickly discover...

that you've completely missed what dan was saying? he (and
Nemo before him) was talking about the ability of Plan 9's
dump to back out changes to kernel, library, and utilitys
uniformly. i don't have a clue what FTP or HTTP mirrors or
"things your OS should do automatically" have to do with
any of this. are we just having unrelated conversations at
each other?
ア