Re: [9fans] spaces in file/dir names? (and acme)?

Re: [9fans] spaces in file/dir names? (and acme)?

[Sam]

Userland needs file names?  What?

On Thu, 30 May 2002, Fco.J.Ballesteros
wrote:

> > Vowels in file names are a curse!  All filenames should have only
> > upper case consonents!  Compare:
> >
> > 	readme.text to RDM.TXT
> >
> > Nuff said!
>
> touche.
> I'll be using qids as file names since now on, as a penitence.
>

Re: [9fans] spaces in file/dir names? (and acme)?

[Fco.J.Ballesteros]

> Vowels in file names are a curse!  All filenames should have only
> upper case consonents!  Compare:
>
> 	readme.text to RDM.TXT
>
> Nuff said!

touche.
I'll be using qids as file names since now on, as a penitence.

Re: [9fans] spaces in file/dir names? (and acme)?

[Axel Belinfante]

The approach could work, but currently I only edit
(because I only see) one path element at a time --
we would have to remember some 'context' information
(names of parent directories).
For the general case probably substfs should build its
own file tree structure (in a demand driven, lazy, way)
(based on the remote one combined with editing script(s)),
use that structure for the directory structure shown to its
user, and use the remote server to access the real data.

I'll send the current code off-line.

Axel.

> Hmm, assuming you have an mp3info like program (which is actually
> inside the mad mp3 player that I'm using in Plan 9) you could generate
> a translation table for your file system. Something like:
>
> translate ' ' to '_' # general case
> translate '/a/b/x.mp3' to 'The Best of Alan Parsons'
> translate '/a/b/y.mp3' to 'All You Wanted to Listen from Alan Parsons'
>
> The table could be generated offline by a script, perhaps.
>
> Regarding the source code, I'd still like to take a look, just for fun.

Re: [9fans] spaces in file/dir names? (and acme)?

[Fco.J.Ballesteros]

Hmm, assuming you have an mp3info like program (which is actually
inside the mad mp3 player that I'm using in Plan 9) you could generate
a translation table for your file system. Something like:

translate ' ' to '_' # general case
translate '/a/b/x.mp3' to 'The Best of Alan Parsons'
translate '/a/b/y.mp3' to 'All You Wanted to Listen from Alan Parsons'

The table could be generated offline by a script, perhaps.

Regarding the source code, I'd still like to take a look, just for fun.

thanks

Re: [9fans] spaces in file/dir names? (and acme)?

[Axel Belinfante]

[I started this as an off-list reply (the 'w.r.t the code' part at the end);
 then I started talking about how 'substfs' works, and decided to send it
 to the list, because it seemed suited there as well. It got a bit long:-( ]

> :  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',
> :  ...
> :  When it is slightly more complete (and there is interest?)
>
> I'd love both to take a look at it and to try it.
> Another use would be to use mp3info as one of your edit
> programs to replace file names
> with the author/title kept inside the mp3.

I'm learning now -- thanks! -- I had not realized there is that info
in mp3 (but now that you mention it, I recall seeing it displayed).
Still, we have to see how easy it is to add to the current approach
I have taken.
Right now the 'substfs' just gets a 9p message from the user,
edits it if needed, forwards it to the remote server (e.g. u9fs),
gets the response from the remote server, edits it if needed,
and returns the (potentially edited) response to the user.
Editing is only done on file names.
So, there is a clear one-to-one mapping between messages.
I'm aware of the fact that this may break, e.g. when editing
the data of a read on a big directory edits it such that
the new filenames are so much longer that the edited data no
longer fits in a single message. It's just a prototype.
The right solution would probably be to keep slightly more
state in substfs.
Also, substfs does just use/handle the fids and qids of the
user resp. the remote server.
This means that if substfs wants to do its 'own' requests to
the remote fs (like: to get (part of) the mp3 data to get to
the mp3 info), it has to choose fids that do not conflict with
those of the user.

Still, an interesting question is whether I could use this
approach for the 'file system stacking problem' I asked
about on the list, about a year ago. The idea of stacking
was the following:
to have one file server (A) that generates a file system
with a regular structure (like the tcp directories in /net or
the mail message directories of upas/fs), and then have a
second file server (B) that adds a file to each of the
subdirectories generated by A, where the name of the
new (added) file is the same for all the subdirectories,
but the contents of the new files depend on the contents
of one or more of the 'original' files in the directory.
And, Ideally, achieving this all in B without having to
make special provisions in A.
The basic idea/question was to use (combine) file servers
in the same way as (text) filters are used in a pipe line.
Some of the replies I got then included references to
existing code that does something like this already;
at that time I only had a look at that code but did
not do anything more -- and I haven't had a recent look at
that code while working on substfs -- probably I should have.


W.r.t. the code -- if you don't mind seeing code that might benefit
from some good reviewing I can send you it 'as is' (as I'm using it
right now), because, of course I would like to clean it up before
'general distribution', but on the other hand it is sort-of working
(sufficiently well for my needs) right now, so I fear it might
take a while before I get to cleaning up.

Regards,
Axel.

Re: [9fans] spaces in file/dir names? (and acme)?

[Fco.J.Ballesteros]

:  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',
:  ...
:  When it is slightly more complete (and there is interest?)

I'd love both to take a look at it and to try it.
Another use would be to use mp3info as one of your edit programs
to replace file names
with the author/title kept inside the mp3.

Re: [9fans] spaces in file/dir names? (and acme)?

[Geoff Collyer]

> [...] and have people who want to uses spaces in file names go through
> a little extra work to use these tools

I think the real problem is that people who *don't* want to use spaces
(or other odd characters) in file names have to do extra work to cope
with files created by those who do want to use spaces.  and as rog and
others observed more clearly, shell and acme quoting are the least of
the problems.  I too was relieved upon first reading intro(2) to see
whitespace in file names banned.

Re: [9fans] spaces in file/dir names? (and acme)?

[rog]

> it's entirely reasonable to optimize for the comman (and
> in this case, simple) case, and have people who want to
> uses spaces in file names go through a little extra work
> to use these tools. it would seem a much more tractable
> problem to make acme/plumbing deal with exact text
> strings - as they pretty much do already - which might
> include spaces than to try and have them figure out
> where the magic delimiters are.

but by using a special "space" character to represent spaces in
filenames you get all your desirable behaviour for free, and don't
have to worry about broken up text (rc-style quotes aren't
synchronisable which doesn't mix well with the generally editable text
in acme and rio), the fact you can no longer parse filenames with sed
or awk, or the visual confusion of having something that looks like
two filenames but is in fact one.  (should acme quote the filename in
its tag text?)

god knows how many times i've written stuff like:

	du -a . | awk '{print $2}'

or (in inferno)

	(n, toks) := sys->tokenize(line, " \t\n");
	filename := hd toks;

by making a literal space illegal in filenames, many things are
simplified; conversely if it's legal, many old assumptions are
potentially broken, and a fair amount of code becomes gratuituously
more complex and error-prone.

i was so happy when i first read that plan 9 didn't allow spaces in
its filenames, "hurray, i can use the backquote operator and not worry
about it!".  i hope we don't have to go back to the old days.

  cheers,
    rog.

Re: [9fans] spaces in file/dir names? (and acme)?

[anothy]

//the things that break are mainly things like
//plumbing and acme tag windows, which derive their
//power from the fact that they treat all text
//equally and _don't_ have to worry about
//complex state like quoting.

but wouldn't it be reasonable for acme/plumbing/etc. to
hold onto this assumption, unless instructed otherwise?
i mean, sure, i don't want the default text expansion to
go looking for quotes every time i click, but we can
already override the default text expansion by sweeping
out the exact text we want.

it's entirely reasonable to optimize for the comman (and
in this case, simple) case, and have people who want to
uses spaces in file names go through a little extra work
to use these tools. it would seem a much more tractable
problem to make acme/plumbing deal with exact text
strings - as they pretty much do already - which might
include spaces than to try and have them figure out
where the magic delimiters are.
ア

Re: [9fans] spaces in file/dir names? (and acme)?

[Russ Cox]

> > Everything starts to break when you deal with spaces
> > in file names.

> I find that interesting since it sounds like regression instead of
> progress.

this is a stupid discussion, but who am i to stop it?

the things that break are mainly things like
plumbing and acme tag windows, which derive their
power from the fact that they treat all text
equally and _don't_ have to worry about
complex state like quoting.  for example, if i
click on this line:

	/usr/rsc/lib/profile

in acme, i don't want it to expand the selection back
and forward until it hits the two apostrophes in my
do not contractions.  so in those contexts, spaces
in file names do break everything.

my point was that acme (and to a lesser extent,
plumbing) don't interact well with spaces in file names.
this is a fundamental problem.

you can pick your poison.  acme employs sensible
defaults that make my editing and interaction with
the system a whole lot easier.  i won't give them up
just to get spaces in my file names.

russ

Re: [9fans] spaces in file/dir names? (and acme)?

[Douglas A. Gwyn]

Dan Cross wrote:
> Perhaps if you use the Unicode space symbol, no one will be able to
> listen to it.

? In Unicode space, no one can hear you scream?

Re: [9fans] spaces in file/dir names? (and acme)?

[Douglas A. Gwyn]

Lucio De Re wrote:
> ... I suppose the word delimiter on the command line could have
> been something less convenient...

That just changes the symptoms.
For fully general processing of "arguments" in the presence of
special-character handling, some form of "escape" is necessary
to prevent unwanted special-character handling.  However, that
in general also requires use of an additional special character.
Just one character can suffice to escape a whole raft of s.c.s.
It helps immensely if different apps that might be used in
conjunction employ *different* escapes (and s.c.s); if you have
ever seen a Unix shell script generating a troff macro, with
perhaps 16 \s in a row needed to get it to collapse to one \ at
the stage where it is needed, you can appreciate the problem.

Re: [9fans] spaces in file/dir names? (and acme)?

[Douglas A. Gwyn]

rsc@plan9.bell-labs.com wrote:
> Everything starts to break when you deal with spaces
> in file names.

I find that interesting since it sounds like regression instead of
progress.
On Unix, the only real problem with spaces in file names was in avoiding
inappropriate parsing of arguments on shell command lines, usually
addressed
by 'quoting'.  Note also that the "xargs" utility, otherwise extremely
useful, was misimplemented in that it did not quote arguments before
invoking commands via a subshell.  (Proper quoting is tricky since there
can be embedded ' " \ NL, etc.  Much better would be to simply pass the
arguments uninterpreted via execv().)

Re: [9fans] spaces in file/dir names? (and acme)?

[Axel Belinfante]

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.

Re: [9fans] spaces in file/dir names? (and acme)?

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

> Probably you didn't listen it enough, AP is like tonic water, gets better
> each time you listen it again (That's why Repeat exists in aplay ☺).

Wow, you listen to tonic water?  :-)

> :  I need to do more soul searching before I really know where I stand on
> :  the space-in-filenames issue.
>
> I thought we had found that `spaces or not' was not the issue.
> So getting back on-topic, should I export for 9fs all the Alan Parsons
> Project files? Or should I wait until 9P changes to admit as legal file
> names only those that start with 'Alan Parsons' (despite the white space)?

Perhaps if you use the Unicode space symbol, no one will be able to listen
to it.  :-)  Hmm, perhaps I shouldn't talk; my music tastes have been
described as distasteful before.

Maybe I should steal brucee's 8-track of Elvis covers.

	- Dan C.

Re: [9fans] spaces in file/dir names? (and acme)?

[Fco.J.Ballesteros]

:  I was thinking of the music.  (No offense, Nemo.)  Those of you who

Probably you didn't listen it enough, AP is like tonic water, gets better
each time you listen it again (That's why Repeat exists in aplay ☺).

:  I need to do more soul searching before I really know where I stand on
:  the space-in-filenames issue.

I thought we had found that `spaces or not' was not the issue.
So getting back on-topic, should I export for 9fs all the Alan Parsons
Project files? Or should I wait until 9P changes to admit as legal file
names only those that start with 'Alan Parsons' (despite the white space)?

Re: [9fans] spaces in file/dir names? (and acme)?

[Dan Cross]

> > I'm sorry.
>
> For the spaces or the music?
>

I was thinking of the music.  (No offense, Nemo.)  Those of you who
read, ``The Onion'' will just have to look out for my pirate radio
station (funnily, I *do* have a copy of Black Flag's `TV Party'
somewhere).

I need to do more soul searching before I really know where I stand on
the space-in-filenames issue.

	- Dan `vive la revolutione' C.

Re: [9fans] spaces in file/dir names? (and acme)?

[jmk]

On Sat Jun  1 17:35:14 EDT 2002, cross@math.psu.edu wrote:
> > 01_Alan_Parsons_The_Time_Machine -> ../realdir/01 Alan Parsons The Time Machine
>
> I'm sorry.
>
> 	- Dan C.

For the spaces or the music?

Re: [9fans] spaces in file/dir names? (and acme)?

[Dan Cross]

> 01_Alan_Parsons_The_Time_Machine -> ../realdir/01 Alan Parsons The Time Machine

I'm sorry.

	- Dan C.

Re: [9fans] spaces in file/dir names? (and acme)?

[Boyd Roberts]

Lucio De Re wrote:
> Specially as there are two vowels in the conventional representation

Conventional representation?  No way -- binary is all we need.

Flatten the character set down to 1 bit.

Re: [9fans] spaces in file/dir names? (and acme)?

[Lucio De Re]

On Thu, May 30, 2002 at 11:13:17AM -0700, Geoff Collyer wrote:
>
> Vowels at least don't bugger parsing and don't require the use of
> quoting schemes, which will become increasingly complicated to deal
> with embedded spaces, newlines, slashes, and NUL bytes, and which will
> make hex file names look appealing.  Vowels can stay.  ?

Specially as there are two vowels in the conventional representation
of hex values.  But no lower case letters, please.
(for the humour impaired, insert smiling face here - my mailer is
still antidiluvian).

++L

Re: [9fans] spaces in file/dir names? (and acme)?

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

>>really?
>>the only ones i could find were misc/unicode.6x13.font and
>>misc/latin1.6x1[30].font.  maybe fonts have been updated for the 4th
>>edition?

you're right.  it has changed.  try it in the office.

>	2420	symbol for space
>is in lucida/unicode.*.font

oh i see!  not having found it in the fonts i'd assumed it was the conventional symbol
for space anciently, but that little SP is not what i'd expected.

[-- Attachment #2: Type: message/rfc822, Size: 1615 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] spaces in file/dir names? (and acme)?
Date: Thu, 30 May 2002 21:16:03 +0100
Message-ID: <20020530201120.CFF9A19AB0@mail.cse.psu.edu>

> i tend to use no-break space (00a0) which has dots in two corners in
> the usual plan 9 fonts, although

really?
the only ones i could find were misc/unicode.6x13.font and
misc/latin1.6x1[30].font.  maybe fonts have been updated for the 4th
edition?

>	2420	symbol for space

is in lucida/unicode.*.font

Re: [9fans] spaces in file/dir names? (and acme)?

[rog]

> i tend to use no-break space (00a0) which has dots in two corners in
> the usual plan 9 fonts, although

really?
the only ones i could find were misc/unicode.6x13.font and
misc/latin1.6x1[30].font.  maybe fonts have been updated for the 4th
edition?

>	2420	symbol for space

is in lucida/unicode.*.font

Re: [9fans] spaces in file/dir names? (and acme)?

[rsc]

i figured he was right and i just was missing something,
but i don't see them either.

maybe the emporer really doesn't have any clothes.
hmm.

Re: [9fans] spaces in file/dir names? (and acme)?

[rog]

> sorry, i told you the wrong character.  2423.

yes i like that (...having finally found a font that displays it).

mind you, then there's the issue of the ambiguity with the genuine
open box character.  at least with 00a0 the loss of that character in
the remote fs is understandable; and it would be nice to be able to
pick a glyph with no other equivalent in unicode (there doesn't seem
to be a "dot below" equivalent to 02d9).

Re: [9fans] spaces in file/dir names? (and acme)?

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

i tend to use no-break space (00a0) which has dots in two corners in
the usual plan 9 fonts, although
	2420	symbol for space
might be better (i assume it's the traditional symbol) except
that it isn't in the few fonts i tried.  fraction slash (2044) differs
from / although it's perhaps a little subtle.

[-- Attachment #2: Type: message/rfc822, Size: 1507 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] spaces in file/dir names? (and acme)?
Date: Thu, 30 May 2002 19:58:29 +0100
Message-ID: <20020530185346.F0EC919ADA@mail.cse.psu.edu>

> or you could use the picture that acme displays for ,
> which looks quite reasonable to me.

it might be just me, but i'd be happier if the visual ambiguity
was avoided as well as the encoding ambiguity.

Re: [9fans] spaces in file/dir names? (and acme)?

[rog]

> or you could use the picture that acme displays for  ,
> which looks quite reasonable to me.

it might be just me, but i'd be happier if the visual ambiguity
was avoided as well as the encoding ambiguity.

Re: [9fans] spaces in file/dir names? (and acme)?

[rsc]

sorry, i told you the wrong character.  2423.

Re: [9fans] spaces in file/dir names? (and acme)?

[rog]

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.

  cheers,
    rog.

Re: [9fans] spaces in file/dir names? (and acme)?

[rsc]

or you could use the picture that acme displays for ␣,
which looks quite reasonable to me.

Re: [9fans] spaces in file/dir names? (and acme)?

[Geoff Collyer]

Vowels at least don't bugger parsing and don't require the use of
quoting schemes, which will become increasingly complicated to deal
with embedded spaces, newlines, slashes, and NUL bytes, and which will
make hex file names look appealing.  Vowels can stay.  ☺

Re: [9fans] spaces in file/dir names? (and acme)?

[Sape Mullender]

> Vowels in file names are a curse!  All filenames should have only
> upper case consonents!  Compare:
>
> 	readme.text to RDM.TXT

Vowels?  It's Characters in file names that are the real curse.

Re: [9fans] spaces in file/dir names? (and acme)?

[presotto]

Vowels in file names are a curse!  All filenames should have only
upper case consonents!  Compare:

	readme.text to RDM.TXT

Nuff said!

Re: [9fans] spaces in file/dir names? (and acme)?

[Geoff Collyer]

Spaces in file names are a curse.  I have to live with them everyday
on Mac OS X, and it's maddening.  File names are supposed to be simple
identifiers, not your whole entire life story, complete with 8×10
colour glossy photos and bibliography.  (Yeah, that's what we can do
with 64k-byte file names: put a little JPEG and the md5 hash of the
file contents in every file name.  User-friendly, like.)

Having said that, we do have whitespace other than the canonical
space, tab and newline available, and these other characters have no
special meaning to most software yet:

00a0	no-break space
2002	en space
2003	em space
2004	three-per-em space
2005	four-per-em space
2006	six-per-em space
2007	figure space
2008	punctuation space
2009	thin space
200a	hair space
200b	zero width space
2420	symbol for space
3000	ideographic space
303f	ideographic half fill space
feff	zero width no-break space

If one *must* put spaces in file names, using one of these will cause
less grief than space, tab or newline, though there is likely to still
be visual confusion for the poor users.

Re: [9fans] spaces in file/dir names? (and acme)?

[Lucio De Re]

On Thu, May 30, 2002 at 06:57:42PM +0200, Fco.J.Ballesteros wrote:
>
> I still dislike file names with spaces because of the madness
> that may cause in scripts and program arguments, but perhaps
> others think otherwise.

Allow is not the same as encourage, and my sentiments are only a
little stronger than yours:  spaces in file names are an unavoidable
curse.  I suppose the word delimiter on the command line could have
been something less convenient...

++L

Re: [9fans] spaces in file/dir names? (and acme)?

[Fco.J.Ballesteros]

I see know why you want spaces in file names...


:  I was trying aplay on a directory of directories of mp3's,
:  mounted via u9fs.

What I do in this case is to make a directory with links to the
mp3s on the unix machine. Then I start aplay on it.

You know, a directory with stuff like

01_Alan_Parsons_The_Time_Machine -> ../realdir/01 Alan Parsons The Time Machine

Re: [9fans] spaces in file/dir names? (and acme)?

[Fco.J.Ballesteros]

However, the support in 9p and the kernel for spaces is
IMHO all that we need. We're now able to

9fs unixmachine
f='file with spaces'
cp /n/unixmachine/$f /n/fs/`{echo $f | sed 's/ /_/g'}

I still dislike file names with spaces because of the madness
that may cause in scripts and program arguments, but perhaps
others think otherwise.

Re: [9fans] spaces in file/dir names? (and acme)?

[Axel Belinfante]

> Everything starts to break when you deal with spaces
> in file names.  Ls -q and various other hacks start to
> deal with it, but we're not there yet.

Probably that's what confused me: I saw it working in ls,
and build my assumptions on that.

Thanks,
Axel.

Re: [9fans] spaces in file/dir names? (and acme)?

[rsc]

> Can acme not deal with spaces in file names?

No.  Most of the system doesn't deal well
with spaces in file names.

> When I tried creating files (touch) and directories (mkdir)
> with names containing spaces on kfs and on fake worm fs,
> that was refused with an error message 'bad character in ... name'.

That's because you don't want to do that.  Really.

> However, intro(5) states
>
>     Plan 9 names may contain any printable character (that is, any
>     character outside hexadecimal 00-1F and 80-9F) except slash.)

The Plan 9 kernel is being discussed there.  Other file servers
may impose their own restrictions.  For example, you can't put
a colon in a dossrv file name.

> But /sys/src/fs/port/9p2.c:155 contains
>
>                 if((*p & 0xFF) <= 040)
>                         return Ename;
>
> and /sys/src/fs/port/sub.c and /sys/src/cmd/disk/kfs/^(9p2.c sub.c)
> contain similar checks.

And, at the moment, you can't put spaces in Plan 9 file server
file names.

Everything starts to break when you deal with spaces
in file names.  Ls -q and various other hacks start to
deal with it, but we're not there yet.  I was tempted a few
years ago to replace spaces with ␣ in dossrv's file names.
We couldn't do that then because of the name length
restrictions (␣ is three precious bytes).

Russ

Re: [9fans] spaces in file/dir names? (and acme)?

[rsc]

> 1+p
> 40

yes.  i believe he was complaining about the boundary
case here.  the 1+, as it were.

Re: [9fans] spaces in file/dir names? (and acme)?

[Boyd Roberts]

Axel Belinfante wrote:
> However, intro(5) states
>
>     Plan 9 names may contain any printable character (that is, any
>     character outside hexadecimal 00-1F and 80-9F) except slash.)
>
> But /sys/src/fs/port/9p2.c:155 contains
>
>                 if((*p & 0xFF) <= 040)
>                         return Ename;
>
> and /sys/src/fs/port/sub.c and /sys/src/cmd/disk/kfs/^(9p2.c sub.c)
> contain similar checks.

% dc
16i 8o
1Fp
37
1+p
40

[9fans] spaces in file/dir names? (and acme)?

[Axel Belinfante]

Can acme not deal with spaces in file names?

I was trying aplay on a directory of directories of mp3's,
mounted via u9fs.
Both the mp3 files and the directories that contain them contain
spaces in their names. When I open acme in such a directory,
the tag contains the directory name upto the first space,
but the body contains the correct directory listing.
If I start 'aplay playprog .' in such a body,
aplay does not list the songs in the current directory,
but the song-directories of which the current directory is one,
i.e. ..  ; it does single-quote these were needed.
Right-mouse-click on such a quoted subdirectory name does not work.

When I tried creating files (touch) and directories (mkdir)
with names containing spaces on kfs and on fake worm fs,
that was refused with an error message 'bad character in ... name'.

However, intro(5) states

    Plan 9 names may contain any printable character (that is, any
    character outside hexadecimal 00-1F and 80-9F) except slash.)

But /sys/src/fs/port/9p2.c:155 contains

                if((*p & 0xFF) <= 040)
                        return Ename;

and /sys/src/fs/port/sub.c and /sys/src/cmd/disk/kfs/^(9p2.c sub.c)
contain similar checks.

Confused,
Axel.