From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200206041623.g54GN8c19674@zamenhof.cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] spaces in file/dir names? (and acme)?
In-reply-to: Your message of "Thu, 30 May 2002 19:16:59 +0100."
             <20020530181217.5C2D019ABA@mail.cse.psu.edu>
References: <20020530181217.5C2D019ABA@mail.cse.psu.edu>
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue,  4 Jun 2002 18:23:08 +0200
Topicbox-Message-UUID: a4e0c03c-eaca-11e9-9e20-41e7f4b1d025

To solve my particular case at hand (playing mp3 files made available
via u9fs, where I don't want to do any special work at the remote end),
I resorted to writing (hacking) what I've named so far 'substfs',
a file server that is supposed to sit between 'the user'
(usually mount) and the remote u9fs, and does do file name substitution.
Apart from the file server that it should work on, it is given
two edit programs (filter scripts) that (should) do the remote->local
and local->remote conversions. The edit programs could then
be 'tr '' '' `{unicode whatever}' (and the reverse).
(actually, I use something like: cat|tcs -f 8859-1| tr ' ' @
 where @ is one of the special space characters mentioned in this thread
 which number I don't recall right now).

So far it seems to work -- even though the editing is not yet done
for all message types, and mememory management is a joke.
I also haven't tried yet what happens if I mount its /srv/bla
file in two different places and try to access it 'simultaniously'.
I built by glueing together bits and pieces taken from u9fs, 9pcon,
lib9p and probably some other places.
When it is slightly more complete (and there is interest?)
I will probably post it to 9fans or it make available via the web.
Writing it has been quite instructive in getting more insight in
the 9p2000 protocol.

Regards,
Axel.

> i quite like the way that spaces in r3 dosfs map to colons (and vice
> versa, presumably).  of course you wouldn't want to do that in general
> 'cos colon is a useful char, but what about that glyph that i've seen
> in Word (i think) that looks like a very small dot at the bottom of
> the line and represents a space; that's fairly unambiguous, and if
> most fonts displayed 0xa0 as that glyph, and if /lib/keyboard mapped
> ALT-space to 0xa0, and imported filesystems mapped 0xa0 1-1 with 0x20,
> we'd have quite a workable situation and no confused
> shellscripts/cut&paste/double-click.