From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave <dave@dave.tj>
Subject: Re: [9fans] blanks in file names
In-reply-to: <20020711020105.C82D119A63@mail.cse.psu.edu> from
 <"anothy@cosym.net"@Jul>
To: 9fans@cse.psu.edu
Message-id: <200207110647.g6B6lI923214@dave2.dave.tj>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Date: Thu, 11 Jul 2002 02:47:18 -0400
Topicbox-Message-UUID: c92a594e-eaca-11e9-9e20-41e7f4b1d025

Reply inline:

 - Dave

anothy@cosym.net wrote:
> 
> 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:
This won't directly solve any userland problems, because it's a kernel
level change.  However, it _will_ provide the foundation necessary for
a real makeover for our shell, so it becomes a true translator between
the kernel and the user (what it was always meant to be).

> 
> 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)?
I remarked in a couple of my previous posts about the subject, but let
me show some examples of what I mean:
Let's say we have a shell that uses C-style encoding, and we're in a
directory called (using a C-syntax string) "/usr/\/\\\n\'blah":
crazysh> pwd
/usr//\
'blah
crazysh> pwd --unambiguous
/usr/\/\\\n\'blah
crazysh> ls
What's wrong with you?
You don't want to know what's in this directory ;-/
crazysh> ls --unambiguous
What\'s wrong with you\?
\0\0\0
You don\'t want to know what\'s in this directory ;-\/
crazysh> exit

You'll notice that the initial pwd command prints the directory in
easy-for-human-to-read format - what it was "meant" to look like.
The second command runs the same program as the first command, but the
_shell_ (not the pwd command!) is given the --unambiguous option so
it prints the resulting path in its native (C-style encoding) format.
(Programs don't produce "text" as output; they produce "objects," which
- as I remarked in a previous post - may be filenames, strings, etc.)
The third command prints a directory listing in easy-for-human-to-read
format, and the fourth tells the shell to print ls' output filenames in
C-style rather than raw form (where you'll notice a file consisting of
nothing but NULLs suddenly appears - a neat trick that can make users
of other OSs quite jealous).

Obviously, a user may opt for a shell using URL encoding as its default
encoding, or even replace the "raw" encoding with URL/C/etc. encoding.
It's all a matter of personal preference, and the kernel isn't involved
at all ... nor is any filesystem code.

> 
> 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.
Well, if you're using C-style syntax, filename edges are simply newlines.
If you're using url encoding, spaces seperate filenames.  If you're using
Base64 (which I believe any human would have to be crazy to do, but I
see no reason for the system to stop crazy people), you'd have plenty
of choices for filename edges.  You just have to make sure the both
sides of the pipe are working with the same encoding.  (e.g., "crazysh>
program-outputting-in-url | program-expecting-in-c" ain't gonna work,
but most of your userland programs would probably ship with your shell
or offer optionss to support your shell's encoding (or if your shell
uses an uncommon encoding, it might provide programs to convert to/from
more common encodings).)

> 
> third: want newline too?
A general solution should handle all cases.  I see no reason not to handle
newlines, too.  (In fact, my example above illustrated a lot more than
mere newlines being encoded.)

> 
> 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?
I was pointing out that yesterday doesn't even attempt to address
the problem I was referring to (keeping an FTP mirror up-to-date).
I (thought I) understood that he was proposing to run a filter on files
he's mirroring.  My answer was quite simply that doing so is unfeasible
on a large scale.  I hope that clarifies a bit :-)

> ア
>