[9fans] experimental change for devmnt to deal with spaces

[9fans] experimental change for devmnt to deal with spaces

[Fco.J.Ballesteros]

This seems to do it.
I'm using it as an experiment.
BTW, is the UTF8 of 0x00a0 0xa0? I think so, but I'm not sure.

One thing I dont like is that this diff makes devmnt to change the
user supplied names. I think it would be better to do it at
convS2M/convM2S, but that scares me. Any comment on this?

If you hate applying diffs, the whole devmnt is at
http://plan9.escet.urjc.es/who/nemo/devmnt.c

Let me know if this convinces you or you're still dubious or
there's a better way.

hth

diff /n/dump/2002/0703/sys/src/9/port/devmnt.c /sys/src/9/port/devmnt.c
77a78,79
> // Ugly, but where would it be better? Perhaps at convS2M/M2S?
> // that would require a change to 9p.
78a81,122
> importname(char *s)
> {
> 	for(; *s; s++)
> 		if (*s == ' ')
> 			*s=0xa0;
> }
> 
> static void
> exportname(char *s)
> {
> 	for(; *s; s++)
> 		if (*s == 0xa0)
> 			*s=' ';
> }
> 
> static void
> exportstat(uchar *s)
> {
> 	int m;
> 
> 	s += STATFIXLEN - 4 * BIT16SZ;	// first string
> 	m = GBIT16(s);
> 	s += BIT16SZ;
> 	for (; m > 0; m--, s++)
> 		if (*s == 0xa0)
> 			*s=' ';
> }
> 
> static void
> importstat(uchar *s)
> {
> 	int m;
> 
> 	s += STATFIXLEN - 4 * BIT16SZ;	// first string
> 	m = GBIT16(s);
> 	s += BIT16SZ;
> 	for (; m > 0; m--, s++)
> 		if (*s == ' ')
> 			*s=0xa0;
> }
> 
> static void
418a463,465
> 	// ␣
> 	for (i = 0; i < nname; i++)
> 		exportname(name[i]);
421d467
< 
486a533
> 		importstat(dp);	// ␣
510a558
> 		exportname(name);
628a677
> 	exportstat(dp);	// ␣
669a719
> 			importstat(p);	// ␣ 

Re: [9fans] experimental change for devmnt to deal with spaces

[Lucio De Re]

On Wed, Jul 03, 2002 at 03:43:19PM -0400, rob pike, esq. wrote:
> 
> You are changing the meaning of the space character.
> Think about what that means, the number of places it
> affects, the impossibility of getting it right
> everywhere.  This is a terrible idea.
> 
I got it!  Use   whenever you need a non-breaking space, it's
a standard!

	% touch 'a x'

will then create file 'a x'.  Pity you still need quotes to escape the
'&' and ';' <grin>

++L

Re: [9fans] experimental change for devmnt to deal with spaces

[FJ Ballesteros]

I saw it more like using two different characters,
and not like changing the meaning of space. 

I'll think about it, but I sincerelly think that
'a x' causes much more problems than a?x, since
for example something like

ls | dosomething

would make dosomething think that a file name with
spaces on it is '/a/b x' instead of /a/b x.
In fact, I think that's what happen with the
'chk file I had to remove to avoid confussing replica.

Perhaps I could see what I may be missing after
gaining more experience with the changed/broken mount driver,
or, if you happen to have some time, you could drop me a line
with some of the bad effects you see. I just can't see them, sorry.


"rob pike, esq." ha escrito:
> 
> You are changing the meaning of the space character.
> Think about what that means, the number of places it
> affects, the impossibility of getting it right
> everywhere.  This is a terrible idea.
> 
> -rob

Re: [9fans] experimental change for devmnt to deal with spaces

[rob pike, esq.]

You are changing the meaning of the space character.
Think about what that means, the number of places it
affects, the impossibility of getting it right
everywhere.  This is a terrible idea.

-rob

Re: [9fans] experimental change for devmnt to deal with spaces

[rog]

> What's the problem? Any of you must be aware of something I'm missing.

to continue with the upas/fs example, here's a function that opens a
mailbox and returns a pathname that can be used to access the messages
therein:

void
openmbox(char *path, char *name, char result[])
{
	fprint(open("/mail/fs/ctl", OWRITE), "open %q %q", path, name);
	sprint(result, "/mail/fs/%s", name);
}

imagine the function being called as follows:

{
	char buf[65536];
	openmbox("/mail/box/rog/mbox", "My\x00A0Mailbox", buf);
}

assuming upas/fs doesn't do the same character translation as the
mount driver, any subsequent code that tries to use the returned path
will fail, as the mailbox will have been created in upas/fs's internal
data structures *with* the 0xa0 character; however the mount driver
prevents that character from getting through.

to my mind, the fact that a pure plan 9 program has to be aware of
this convention to work correctly seems to indicate that the best
solution is at the boundaries of the system - i.e.  whereever a plan 9
fileserver interacts with an external name.

that keeps internal invariants simple, and the potential for peril low.

  rog.

Re: [9fans] experimental change for devmnt to deal with spaces

[FJ Ballesteros]

I hate to disagree with Rob, but after thinking more about it,
I think that %q actually broke the system interface and
that a better way is needed. The are many examples, most of them of
form 

	program_using_%q | program_using_' '_as_delimiter.

IMHO, the can of worms is already open (rog gave even more examples)
and we can either eat
the worms (which was my first option, i.e. if you have problems
with ' ', don't use ' '), or close the can again.

I'd really love to see an example where the proposed change
would actually break the system.
I've tried as hard as I could to find one, but I found none.

rog:
> but i really don't think this is in the right place, as it affects
> *every* user-level implemented fileserver, and it's quite possible
> that a fileserver produces in a file names that have been created
> inside it.  (e.g.  think of upas/fs, "create mboxname").

I've thought about that, but even in this case the system would still
work properly:
	Let's say a file server creates a file with a line per
	file created on it. The line contains the created file name,
	just to follow your example.
	Say you create w\x0aw, the file server would write
	"w w\n" to the file with file names (that's the name it sees).
	If you later try to read and use those file names, they will work,
	becase "w w" is also understood by the system (the space is kept,
	and retains its meaning). 

	Moreover, by doing the change in the kernel, you can replace the
	server software by a different program (using the same media) and
	it will still work (since the server still sees 'w w'. That would
	not happen if it was the server the one translating from Alt-spc to
	spc (because the other server could get confussed).

What's the problem? Any of you must be aware of something I'm missing.
I'd love any of you to prove me wrong so I could learn from this. Just
give
me an example if you don't have time to teach me.

thanks a lot in any case.

PS: One point where I think we were wrong is that the character should
be one such that it's length be 1, to avoid changing name lengths, sic.

Re: [9fans] experimental change for devmnt to deal with spaces

[rog]

nemo:
> BTW, is the UTF8 of 0x00a0 0xa0? I think so, but I'm not sure.

no rune above 127 has the same representation in utf8.  (0xa0 is
represented by [0xc2, 0x80]).

that means your job is a little harder as you have to grow the
messages.

but i really don't think this is in the right place, as it affects
*every* user-level implemented fileserver, and it's quite possible
that a fileserver produces in a file names that have been created
inside it.  (e.g.  think of upas/fs, "create mboxname").

however i still think it shouldn't be too bad if done at the
boundaries of the system, where one is less likely to have such things
going on, and where one is notionally crossing a language boundary
anyway (e.g.  one doesn't expect a Windows filesystem to have files
containing filenames in plan 9 format).

rob:
> Change space!

actually i thought i was on the side of *not* changing space!  space
in plan 9 was always a character that could be used to separate
filenames unconditionally; now it's not, and that change affects many
things.

a few things that are affected:

* filenames of the same length no longer take the same number of
characters.

* {ls | sort -f} no longer works.  (in fact sort probably needs to
understand quoting for its field separators, as probably do several
other tools).

* regexps for matching filenames become much more complex, and
non-determinate, as we don't know which characters were inside or
outside the quotes.  acme right-button semantics can never work
properly on quoted filenames.

* greater potential for visual misidentification of distinct
filenames: i think that it's more difficult to pick out the filenames
in:
	'A few very  ''long file'    names 'in the same  '   place
than in:
	A_few_very__'long_file    names in_the_same__   place
(substituting '_' for whatever the "space" char is), as there's an
immediate indication of which spaces are separators and which are part
of the filenames.

* the fact that spaces run together visually provides great
possibilities for ambiguities in filenames (not that that isn't an
issue with unicode anyway :-])

* echo no longer works reliably as a convenient way of selecting filenames:
e.g.
	% echo *.txt
	x.txt y.txt z.txt
	% ls -l
	--rw-rw-r-- M 32 rog rog 1 Jul  3 18:31 x.txt y.txt
	--rw-rw-r-- M 32 rog rog 1 Jul  3 18:31 z.txt

oh well.

  rog.