Re: [9fans] blanks in file names

Re: [9fans] blanks in file names

[Fco.J.Ballesteros]

rog@vitanuova.com :
:  /sys/src/cmd/dossrv
:  /sys/src/cmd/9660srv
:  /sys/src/cmd/tapefs
:  /sys/src/cmd/unix/u9fs
:  /sys/src/cmd/ftpfs
:  	convert "space char" to/from external actual space on create,
:  	walk, wstat, stat and directory reads.

One crazy idea I had was to do that translation in the mount driver.
That way the server would be happy to think that it uses space, and
the client plan 9 program would be happy to see 00A0 or whatever
without confussion with the space character. 

lucio@proxima.alt.za : 
:  What I'm saying, is that I'd like to target a kernel that is entirely
:  delimiter agnostic and promote each user application in the same
:  direction as a long-term project.  In the interim, constructs that
:  cast delimiters in stone should be removed wherever possible.

IMHO, the problem is mostly the user programs and not the kernel.
AFAIK, the kernel is fine if you don't use / and \0 as delimiters
(which seems reasonable to me, although some guys might want to use it too). 

But the tradition that blanks separate arguments is deeply embedded in
user programs, perhaps most notably the shell.

Assume the kernel has changed to use openv[], what would the shell
do to deal with spaces vs 00A0s ?

Re: [9fans] blanks in file names

[Lucio De Re]

*** ramble alert! ***

On Wed, Jul 03, 2002 at 10:00:55AM +0200, Fco.J.Ballesteros wrote:
> 
> IMHO, the problem is mostly the user programs and not the kernel.
> AFAIK, the kernel is fine if you don't use / and \0 as delimiters
> (which seems reasonable to me, although some guys might want to use it too).
> 
Yes, it would be convenient for the delimiter to be soft, for example.

> But the tradition that blanks separate arguments is deeply embedded in
> user programs, perhaps most notably the shell.
> 
I certainly will not argue with this.

> Assume the kernel has changed to use openv[], what would the shell
> do to deal with spaces vs 00A0s ?
> 
Well, it's not as if I'm the genius here :-)
  
The command line (ignore the shell for a moment as its interpreter)
is a very clear expression of the user's intent, in that there is
a long tradition behind it and, eqaully important(ly), it is visually
unambiguous (within human limits).    The feature one often overlooks
of spaces is that they can be repeated with no change of semantics
or replaced by other whitespace with similar results (cf. sendmail's
configuration file and its tab/space madness).

So it would seem reasonable to retain the convention unchanged in
the familiar contexts and seek alternatives in the new, graphical
environments, for example.  Is there perhaps an undiscovered
technique to express a shell pipeline in a graphical format?  If
so, can new separator rules be brought to apply, escaping some of
the limitations of the traditional approach?

Maybe facetiously, I'd like to point out that the space is the
absence of a character to the eye, if we used a typescript interface
with pixel-dots in the character positions, drag-and-dropping
command line parameters would be automatically quoted by the
background pixel-dots.  That is, until you want a pixel-dot character
in an argument. Sigh.

Still, a background of single quotes would work and be horrendously
ugly, argument completion may become mandatory as the shell now no
longer can provide that function as everything is quoted.

In short, no, I do not have an answer for Nemo, but it seems to me
that bending the conventional interface is not going to work well,
we ought to be looking for new answers, not unlike the ingeniousness
that brought us Plan 9 in the first place and acme as the most
extreme example.

++L

Re: [9fans] blanks in file names

[rob pike, esq.]

You guys are all arguing about system stuff but it's the
*user interface* that you're really arguing about, and
breaking.  You are opening a can of worms you will never
get closed again.  Change space! Change the file delimiter!
The shell will never recover.  The system will break.
I will mourn.

-rob

Re: [9fans] blanks in file names

[Dave]

How about representing paths internally as connected structures (linked lists, if you will), each of which identifies a particular node.  The method of representation of a given node can be quite flexible (allowing node completion - or as I would term it, cannonization - to be done by the kernel), and user programs could establish their own conventions for dealing with user input and user output (which seems logical to me, since the kernel really isn't intended to be a human user interface, only a program "user" interface).

Here's an off-the-top-of-my-head example to illustrate what I mean.  I'm sure we can come up with a much better system if we all think about this a bit, and figure out how it can be improved (or how it can be replaced with something even better - the purpose of this example is simply to get us thinking in a particular direction that I believe is quite promising):

struct node_t {
 char* name; size_t name_l; /* the node name, and the length of the name */
 /* An error should probably be returned by the kernel if hint is ambiguous. */
 char* hint; /* a regexp that can be fed to attempt to "autocomplete" */
 size_t inode; /* another unique identifier for a node - should we allow it? */
 node_t* next_node;
};

/* canonize(2) converts a node_t chain into its canonical form, expanding all
 *  hints into the corresponding names.  If there are any possible
 *  canonizations and dst is not NULL, dst is filled with node_t chains
 *  representing all the possible canonizations of the node_t chain given.
 * PARAMETERS
 *  src is the node_t chain that you're attempting to canonize.  It's probably
 *   obtained by parsing the input to our shell, and deciding how to interpret
 *   it.
 *  On calling canonize(2), dst should point to a memory block large enough to
 *   accomodate *dst_l node_t structs.  canonize(2) will use the memory block to
 *   store all the nodes of all the node_t chains it creates.
 *  On return from canonize(2), dst_l will be changed to the number of node_t
 *   chains representing possible canonizations (i.e., it's a value-result
 *   parameter), and the first dst_l locations in dst will contain the starting
 *   nodes of the node_t chains representing the possible canonizations.
 * RETURN VALUE
 *  0 on success
 *  -1 on failure, with errno set appropriately
 *  Multiple matches is counted as an error condition, since canonize(2) failed
 *   to canonize the node_t chain.
 *  If dst is too small, dst will be filled as much as possible, but an error
 *   will still be returned.
 * NOTES
 *  Having the self-referencing pointer in node_t refer to the previous node
 *   instead of the next node would allow canonize(2) to save lots of buffer
 *   space in dst for ambiguities that occur deep inside a long node_t chain.
 *   However, I don't believe we should do that, since (a) ambiguities that
 *   occur relatively early in a long node_t chain allow canonize(2) to save
 *   lots of buffer space in dst in the current implementation; and more
 *   importantly, (b) any other routine in the kernel that deals with node_t
 *   chains will have to walk the entire linked list before processing anything
 *   if we implement that change, since the pointer it'll see won't be to the
 *   start of the "pathname," but rather to the end.
 */
int canonize (const node_t* src, node_t dst[], size_t* dst_l);

int new_open (const node_t* path, int flags, int mode);
/* The old open(2) can instead become open(3), with a rather trivial
 *  implementation:
 * int open (const char* path, int flags, int mode) {
 *  split path on unescaped '/' chars;
 *  create a node_t for each of the components obtained above;
 *  link the nodes together into a chain;
 *  return openv(our_node_t_chain,flags,mode);
 * };
 */

/* Here's one final example - the reason I resist the name openv(2): */
int new_execve (const node_t* path, char* const argv[], char* const envp[]);
/* The "v" here refers to a different aspect of the function.  I don't like
 *  overloading the meaning, because we'd have to call our new execve(2)
 *  execvev(2) or something, and that'd be a little insane, IMHO.  That's why I
 *  chose the "new_" prefix.
 * In reality, I'd much rather see the old open(2) be renamed to old_open(2),
 *  and have the new_open(2) be renamed to just plain open(2), damning backward
 *  compatibility (and likewise with the exec(2) family, as well as the stat(2)
 *  call, etc.).  Programs that expect open(2) to be the old open and don't feel
 *  like asking their authors for a rewrite can simply use a runtime library to
 *  rename old_open(2) to open(2) and hide our new open(2) entirely (since
 *  they're obviously not going to use it, anyway).  However, I'm afraid this
 *  type of drastic change may catch some people off-guard.
 */

Dave Cohen <dave@dave.tj>


rob pike, esq. wrote:
> 
> You guys are all arguing about system stuff but it's the
> *user interface* that you're really arguing about, and
> breaking.  You are opening a can of worms you will never
> get closed again.  Change space! Change the file delimiter!
> The shell will never recover.  The system will break.
> I will mourn.
> 
> -rob
> 

Re: [9fans] blanks in file names

[arisawa]

If '/' is prohibitted as an element of file name and directory name,
then no change to open is required.

Let's assume we accept '/' as an element of names,
then how do you express path in rc?

/bin/awk may be :
1. /bin/awk as it has been.
2. a file named "/bin/awk" in current directory.
3. a file named "bin/awk" in "/"
4. a file named "awk" in "/bin" and "/bin" is in current directory.

Kenji Arisawa

Re: [9fans] blanks in file names

[Dave]

For userland programs, I'd probably vote to simply escape "interesting"
characters that occur within filenames:

1) /bin/awk
2) \/bin\/awk
3) /bin\/awk
4) \/bin/awk

We'd still have to annoy sed, awk, sort, etc. with this approach, but I
don't think that's too bad.  (If we really want, we can establish escape
sequences that don't have these chars in them: e.g., \s for slash, \_
for space, etc.)

Just my penny pair,
Dave Cohen <dave@dave.tj>


arisawa@ar.aichi-u.ac.jp wrote:
> 
> If '/' is prohibitted as an element of file name and directory name,
> then no change to open is required.
> 
> Let's assume we accept '/' as an element of names,
> then how do you express path in rc?
> 
> /bin/awk may be :
> 1. /bin/awk as it has been.
> 2. a file named "/bin/awk" in current directory.
> 3. a file named "bin/awk" in "/"
> 4. a file named "awk" in "/bin" and "/bin" is in current directory.
> 
> Kenji Arisawa
> 

Re: [9fans] blanks in file names

[arisawa]

Another escape may be a % of that is used in URI.

%	->	%25
/	->	%2f
space	->	%20

and if open can accept these, new_open is not reqired.

Kenji Arisawa

Re: [9fans] blanks in file names

[arisawa]

>new_open is not reqired.
I should have added:
But I prefer new_open for kernel interface.

Kenji Arisawa

Re: [9fans] blanks in file names

[Dave]

The idea behind our new open(2) is to create a cleaner representation
for paths.  If we want, we can patch the old open(2) - which could
become a library function open2(3) - to support one or more of the
userland naming conventions we were discussing.  However, I don't think
the kernel should meddle with userland naming conventions; having the
kernel deal with binary data in linked lists is by far the cleanest
approach proposed thus far, IMHO.  It also opens the door to all sorts
of neat possibilities for path manipulation without string manipulation.
Finally, it gives us the capability of getting away from even the most
elementary requirements in a filesystem (like inodes) at some point in
the future without extensive code changes.  Basically, it's all about
flexibility, a long-time strength of the UNIX system which has only been
improved upon in Plan 9.

 - Dave


arisawa@ar.aichi-u.ac.jp wrote:
> 
> Another escape may be a % of that is used in URI.
> 
> %	->	%25
> /	->	%2f
> space	->	%20
> 
> and if open can accept these, new_open is not reqired.
> 
> Kenji Arisawa
> 

Re: [9fans] blanks in file names

[Dave]

Oops ... I guess I replied a little too early ;-/

 - Dave


arisawa@ar.aichi-u.ac.jp wrote:
> 
> >new_open is not reqired.
> I should have added:
> But I prefer new_open for kernel interface.
> 
> Kenji Arisawa
> 

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Dave]

I think that'll do more to break current conventions than redoing the
kernel to allow for analogues of our current conventions.

 - Dave


arisawa@ar.aichi-u.ac.jp wrote:
> 
> >What if files 'a b' and 'a_b' both exist on the foreign
> >system?
> Check before you copy, otherwise one is lost.
> This problem is always happen when one to one mapping is
> absent.
> 
> Kenji Arisawa
> 

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[arisawa]

Copy Restriction:
	Check before you copy, otherwise some of them may be lost
Import Resrinction:
	Files containg spaces in name is harmful, so they may be  
lost.
Export Restriction:
	Winland is against freedom, so some of files may be lost.

>I think that'll do more to break current conventions than redoing  
the
>kernel to allow for analogues of our current conventions.
>
> - Dave
>
>
>arisawa@ar.aichi-u.ac.jp wrote:
>>
>> >What if files 'a b' and 'a_b' both exist on the foreign
>> >system?
>> Check before you copy, otherwise one is lost.
>> This problem is always happen when one to one mapping is
>> absent.
>>
>> Kenji Arisawa
>>

Re: [9fans] blanks in file names

[Dave]

If I had to vote a priori, blanks would certainly be a no-go for
filenames.  However, the pressure cooker has already burst, and our
chicken is headed straight towards the ceiling.  Getting rid of spaces in
filenames is not much of an option, if we want to be able to get along
in the wide world of non-space-restricted systems.  (One simple way to
realize that s/ /anything/g isn't a very clean option is to note that
different domains are going to require humans to determine how to do the
conversion (and its inverse) and in what contexts to do each of the above.
Maintaining an FTP mirror, for instance, is not going to be easy at all.)
Rethinking our system to fully support blanks, IMHO, is the only way to
keep our chicken from splattering all over the kitchen ;-/

 - Dave


arisawa@ar.aichi-u.ac.jp wrote:
> 
> >Isn't this thread dead yet?
> It seems ...
> So I asked: Is it important?
> So I said: My preference is just s/ /_/g
> So I proposed: uq (unquote)
> Any way, I dislike ' ' in file name.
> 
> Kenji Arisawa
> 

Re: [9fans] blanks in file names

[arisawa]

Dave wrote:
>If I had to vote a priori, blanks would certainly be a no-go for
>filenames.  However, the pressure cooker has already burst, and our
>...
>keep our chicken from splattering all over the kitchen ;-/

Important or not? That is the problem.
If we agree it is important, we must eat spaes.
Then my chice is to cook spaces so that stomach is not broken.
How to cook?
I believe the first discussion should be forcussed
to expression of path considering in future needs.
I believe you and I share much opinion.

Kenji Arisawa

[9fans] Re: blanks in file names

[Jim Choate]

On Wed, 10 Jul 2002, Dave wrote:

> If I had to vote a priori, blanks would certainly be a no-go for
> filenames.  However, the pressure cooker has already burst, and our
> chicken is headed straight towards the ceiling.  Getting rid of spaces in
> filenames is not much of an option, if we want to be able to get along
> in the wide world of non-space-restricted systems.

Um, strictly speaking for most OS'es (and logically in general) the
'string' that represents the filename canonicaly -should- be (usually) ""
delimited.

In other words,

ls filename.foo

should really be,

ls "filename.foo"

or perhaps,

ls "file/"Bill/".foo"

The fact that the OS allows one to drop them (assuming you don't use
things like blanks in filenames) is really a courtesy of the shell
implimentation. That's where it should stay. Why the filesystem would
-ever- need the filename for internal operations would, at least to my
mind, be a major error in implimentation. Other than in 'friendly name'
situations (ie UI related) the system should be oblivious of the filename.

If it's a valid character in the character set, it should be allowed in a
string (except for logical issues - eg printing some non-printable) should
print some sort of symbol allowing one to recognize this. This
'conversion' should also stay strictly in the UI related code. To do
otherwise raises a host of issues about side effects and special cases w/
regard to sting handling libraries. To not allow spaces in filenames only
makes the world more complicated. It also destroys a layer of generality,
and that is -almost always- a BAD thing.

With respect to filenames, it's a string of -reasonably- unique (re issues
of location and such) 1's and 0's to the OS. It doesn't really 'mean'
anything to the OS::File System. It's the User::UI that it matters to.

User::UI::OS::File System

Leave the problem where it belongs, in the cli/shell.


 --
    ____________________________________________________________________

              When I die, I would like to be born again as me.

                                            Hugh Hefner
     ravage@ssz.com                                         www.ssz.com
     jchoate@open-forge.org                          www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] Re: blanks in file names

[Dave]

If you're going to rewrite the UI programs (like ls) to print filenames
in human-readable format, you'll need to make an option in each program
that outputs filenames to make it output the names in human-readable or
other-program-readable format ... yucky. . .

 - Dave


Jim Choate wrote:
> 
> 
> On Wed, 10 Jul 2002, Dave wrote:
> 
> > If I had to vote a priori, blanks would certainly be a no-go for
> > filenames.  However, the pressure cooker has already burst, and our
> > chicken is headed straight towards the ceiling.  Getting rid of spaces in
> > filenames is not much of an option, if we want to be able to get along
> > in the wide world of non-space-restricted systems.
> 
> Um, strictly speaking for most OS'es (and logically in general) the
> 'string' that represents the filename canonicaly -should- be (usually) ""
> delimited.
> 
> In other words,
> 
> ls filename.foo
> 
> should really be,
> 
> ls "filename.foo"
> 
> or perhaps,
> 
> ls "file/"Bill/".foo"
> 
> The fact that the OS allows one to drop them (assuming you don't use
> things like blanks in filenames) is really a courtesy of the shell
> implimentation. That's where it should stay. Why the filesystem would
> -ever- need the filename for internal operations would, at least to my
> mind, be a major error in implimentation. Other than in 'friendly name'
> situations (ie UI related) the system should be oblivious of the filename.
> 
> If it's a valid character in the character set, it should be allowed in a
> string (except for logical issues - eg printing some non-printable) should
> print some sort of symbol allowing one to recognize this. This
> 'conversion' should also stay strictly in the UI related code. To do
> otherwise raises a host of issues about side effects and special cases w/
> regard to sting handling libraries. To not allow spaces in filenames only
> makes the world more complicated. It also destroys a layer of generality,
> and that is -almost always- a BAD thing.
> 
> With respect to filenames, it's a string of -reasonably- unique (re issues
> of location and such) 1's and 0's to the OS. It doesn't really 'mean'
> anything to the OS::File System. It's the User::UI that it matters to.
> 
> User::UI::OS::File System
> 
> Leave the problem where it belongs, in the cli/shell.
> 
> 
>  --
>     ____________________________________________________________________
> 
>               When I die, I would like to be born again as me.
> 
>                                             Hugh Hefner
>      ravage@ssz.com                                         www.ssz.com
>      jchoate@open-forge.org                          www.open-forge.org
> 
>     --------------------------------------------------------------------
> 
> 

Re: [9fans] blanks in file names

[Dave]

Eh, I tire of the discussion ... let's just make a userland fix or
whatever ... if it bugs me too much, I'll just patch up the kernel,
or something. . .

 - Dave


arisawa@ar.aichi-u.ac.jp wrote:
> 
> Dave wrote:
> >If I had to vote a priori, blanks would certainly be a no-go for
> >filenames.  However, the pressure cooker has already burst, and our
> >...
> >keep our chicken from splattering all over the kitchen ;-/
> 
> Important or not? That is the problem.
> If we agree it is important, we must eat spaes.
> Then my chice is to cook spaces so that stomach is not broken.
> How to cook?
> I believe the first discussion should be forcussed
> to expression of path considering in future needs.
> I believe you and I share much opinion.
> 
> Kenji Arisawa
> 
> 

Re: [9fans] blanks in file names

[Dave]

/me shudders at the thought that GUIs might someday take over the
world :-(

 - Dave

BTW - The point I was trying to make is that if the kernel doesn't use
any particular filename-rewriting rule, then user programs and libraries
are free to use URL, HTML, quoting, C-style escaping, or any other
system that suits the application at hand, without having to rewrite
their versions into whatever rewriting rule the kernel decides to use.
(I guess you can say I'm "pro choice.")


arisawa@ar.aichi-u.ac.jp wrote:
> 
> Hello,
> 
> > One of the beautiful things about Plan 9 is that it provides a  
> solution
> > that's workable with little effort.  The various substitution file
> > systems provide a workable solution without introducing any  
> additional
> > complexity.  If you want a total--100% complete--solution, then a
> > `urlifyfs' can be written that uses URL escaping as a canonical
> > representation, or something similar.  The system interface  
> doesn't
> > have to be changed, though.  *That* is the mark of a clean system
> > design.
> The idea was born from the discussion between Dave and I.
> Dave proposed '\' escape.
> Until that time, I had been tied to quoting strategy.
> %XX looks ugly as Dave says, but it works cleanly.
> That is the beauty.
> We must be patient with this ugliness because we are in textual
> environment. Full GUI environment, I believe Plan9 also have it
> in future, will remove this ugliness.
> Thanks Dave.
> 
> Kenji Arisawa
> 

Re: [9fans] blanks in file names

[Jim Choate]

On Sun, 14 Jul 2002, Dave wrote:

> /me shudders at the thought that GUIs might someday take over the
> world :-(

I also, it means that mankind will have missed the entire point of
computing.


 --
    ____________________________________________________________________

              When I die, I would like to be born again as me.

                                            Hugh Hefner
     ravage@ssz.com                                         www.ssz.com
     jchoate@open-forge.org                          www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] blanks in file names

[arisawa]

Hello,

Dave, you should be aware that you started from wrong place.
As I said, your new_open is not required.
You speek too much about that is not required.
And I am surprised to see:
>then user programs and libraries
>are free to use URL, HTML, quoting, C-style escaping,
>or any other system that suits the application at hand

Kenji Arisawa

Re: [9fans] blanks in file names

[Boyd Roberts]

Dave wrote:
 > The method of representation of a given node can be quite flexible
 > (allowing node completion - or as I would term it, cannonization
 > - to be done by the kernel),

I thought the making of saints wasn't exactly in the kernel's job 
description.

Re: [9fans] blanks in file names

[Dave]

It's possible that cannonization should still be done by library routines,
but I'd vote to let the kernel do it anyway for whatever optimizations
it can make (since it's not restricted to the standard syscalls for
file handling).

 - Dave


Boyd Roberts wrote:
> 
> Dave wrote:
>  > The method of representation of a given node can be quite flexible
>  > (allowing node completion - or as I would term it, cannonization
>  > - to be done by the kernel),
> 
> I thought the making of saints wasn't exactly in the kernel's job 
> description.
> 
> 

Re: [9fans] blanks in file names

[Boyd Roberts]

Dave wrote:

>It's possible that cannonization should still be done by library routines,
>
Yes, put it in libpope.

Re: [9fans] blanks in file names

[Dave]

Whoops ... I misspelled that one.  A more appropriate comment for you,
though, would have been to put it in libarms ;-P

 - Dave


Boyd Roberts wrote:
> 
> Dave wrote:
> 
> >It's possible that cannonization should still be done by library routines,
> >
> Yes, put it in libpope.
> 
> 

Re: [9fans] blanks in file names

[Berry Kercheval]

Boyd Roberts <boyd@strakt.com> writes:

> Dave wrote:
>  > The method of representation of a given node can be quite flexible
>  > (allowing node completion - or as I would term it, cannonization
>  > - to be done by the kernel),
> 
> I thought the making of saints wasn't exactly in the kernel's job
> description.


Naw, making saints is "canonization".  Making artillery is a perfectly
good kernel task.

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Fco.J.Ballesteros]

> We need not distinguishing 'a b' from 'a_b' because there are
> no files that contains ' ' in their names.

I'm glad to be at home again ☺
Things are so easy now...

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Lucio De Re]

On Tue, Jul 09, 2002 at 09:50:10AM +0200, Fco.J.Ballesteros wrote:
> 
> > We need not distinguishing 'a b' from 'a_b' because there are
> > no files that contains ' ' in their names.
> 
> I'm glad to be at home again ?
> Things are so easy now...

Wrong!  What if files 'a b' and 'a_b' both exist on the foreign
system?  Back to the drawing board, everyone, the problem needs
another, slightly more focussed iteration.

++L

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[arisawa]

>What if files 'a b' and 'a_b' both exist on the foreign
>system?
Check before you copy, otherwise one is lost.
This problem is always happen when one to one mapping is
absent.

Kenji Arisawa

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Lucio De Re]

On Tue, Jul 09, 2002 at 05:42:47PM +0900, arisawa@ar.aichi-u.ac.jp wrote:
> 
> >What if files 'a b' and 'a_b' both exist on the foreign
> >system?
> Check before you copy, otherwise one is lost.
> This problem is always happen when one to one mapping is
> absent.
> 
Well, for DOS and derivative works, "\" ought to be a perfect
translation <evil grin>.

For Unix, there doesn't seem to be a natural replacement for space.
We could use the suggestion of using URL-style encoding, where %
becomes reserved and _any_ special character can be represented as
%XX.  In fact, is there _any_ service for a foreign filesystem that
would defeat such a scheme?

Would such a shim need to be an option in "mount"?

++L

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[arisawa]

>For Unix, there doesn't seem to be a natural replacement for space.
>We could use the suggestion of using URL-style encoding, where %
>becomes reserved and _any_ special character can be represented as
>%XX. In fact, is there _any_ service for a foreign filesystem that
>would defeat such a scheme?
URL-style encoding is powerfull enough and that is internet  
standard.
I believe no system defeats such a scheme.
I don't know why Plan9 rejects to accept this scheme,
if we must (probably we must) deal with outside system,

Kenji Arisawa

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Lucio De Re]

On Tue, Jul 09, 2002 at 06:43:17PM +0900, arisawa@ar.aichi-u.ac.jp wrote:
> 
> >For Unix, there doesn't seem to be a natural replacement for space.
> >We could use the suggestion of using URL-style encoding, where %
> >becomes reserved and _any_ special character can be represented as
> >%XX. In fact, is there _any_ service for a foreign filesystem that
> >would defeat such a scheme?
> URL-style encoding is powerfull enough and that is internet  
> standard.
> I believe no system defeats such a scheme.
> I don't know why Plan9 rejects to accept this scheme,
> if we must (probably we must) deal with outside system,
> 
There are only three characters from a foreign system that need
translation: "%", "/" and " ".  Long filenames are already catered
for in 4ed, perhaps we can extend "lnfs" to deal, optionally, with
this translation.

++L

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[matt]

> There are only three characters from a foreign system that need
> translation: "%", "/" and " ".  Long filenames are already catered
> for in 4ed, perhaps we can extend "lnfs" to deal, optionally, with
> this translation.

is # a consideration?  It's a valid filename char on FreeBSD

Liberating the filename (Was: [9fans] acme question + diffs for kfs, fs and plumbing)

[Lucio De Re]

On Tue, Jul 09, 2002 at 11:54:21AM +0100, matt wrote:
> 
> is # a consideration?  It's a valid filename char on FreeBSD

I think it's valid in a Plan 9 filename, but if not, it's easy to
expand the list to deal with it.

Which reminds me, if we use

fpath = (usr lucio fname)

as a future description of a filepath, how do we designate the
root?

fpath = ('' usr lucio fname)

perhaps?

++L

Re: Liberating the filename (Was: [9fans] acme question + diffs for kfs, fs and plumbing)

[arisawa]

>Which reminds me, if we use
>fpath = (usr lucio fname)
>as a future description of a filepath, how do we designate the
>root?
>fpath = ('' usr lucio fname)
>perhaps?
No, they should be:
fpath = /usr/lucio/fname
as it has been.
No change is required for rc.

Kenji Arisawa

Re: Liberating the filename (Was: [9fans] acme question + diffs forkfs,

[Douglas A. Gwyn]

arisawa@ar.aichi-u.ac.jp wrote:
> [Lucio De Re wrote:]
> >Which reminds me, if we use
> >fpath = (usr lucio fname)
> >as a future description of a filepath, how do we designate the
> >root?
> >fpath = ('' usr lucio fname)
> >perhaps?
> No, they should be:
> fpath = /usr/lucio/fname
> as it has been.
> No change is required for rc.

Wrong!  If we use lists instead of embedded / characters, as stipulated.

The '' member (without quotes in the actual list member, which has
0 characters) would certainly be analogous to the current method
of differentiating between relative and absolute paths.  Is there
some way of getting rid of absolute paths?  What if first member
"bin" or "dev" etc. were bound to "float" to the current dir.?

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[arisawa]

I guess that someone (probably nemo) has already fixed acme
so that we can enter into '/n/c/My Document/' using mouse.
Or already fixed in official update?

Kenji Arisawa

Re: [9fans] blanks in file names

[Fco.J.Ballesteros]

>> But above all, I will undo the changes made in this respect to my
>> local system if you guys or the system designers choose a different way.
...
> Undoing kernel-level changes won't be easy, especially when people start

9fs dump
cp blah blah

Sorry, couldn't resist. I just love this system :-)

Re: [9fans] blanks in file names

[Dave]

You're not going to do that every time you make a change to the
filesystem.  Besides, that won't undo all the "changes" to all the
new programs that lack complexity because they don't have to reinvent
the wheel.

 - Dave


Fco.J.Ballesteros wrote:
> 
> >> But above all, I will undo the changes made in this respect to my
> >> local system if you guys or the system designers choose a different way.
> ...
> > Undoing kernel-level changes won't be easy, especially when people start
> 
> 9fs dump
> cp blah blah
> 
> Sorry, couldn't resist. I just love this system :-)
> 

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Dave]

AFAIK, VFAT uses Unicode for its long file names, so I see no reason
why ␣ shouldn't be allowed there.

 - Dave


Fco.J.Ballesteros wrote:
> 
> : Wrong!  What if files 'a b' and 'a_b' both exist on the foreign
> : system?  Back to the drawing board, everyone, the problem needs
> : another, slightly more focussed iteration.
> 
> I'm renaming ' ' with ␣ in u9fs
> There's no problem doing that since there's no ␣
> in outside file names.
> 

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Dave]

...so clearly, there's no way to distinguish between a file 'a b' and a
file 'a␣b' in a remote filesystem if we replace ' ' with '␣' upon
importing to our system :-(

 - Dave


Fco.J.Ballesteros wrote:
> 
> This is a multi-part message in MIME format.
> --upas-gyhymjcadgjxkouzirlpoqbniv
> Content-Disposition: inline
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: 8bit
> 
> There's no reason.
> I though of using ☺, but I think it's more
> usual in file names than ␣.
> 
> --upas-gyhymjcadgjxkouzirlpoqbniv
> Content-Type: message/rfc822
> Content-Disposition: inline
> 
> Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Tue Jul  9 17:41:20 MDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id 42B8F19A58; Tue,  9 Jul 2002 11:41:09 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from mta9.srv.hcvlny.cv.net (mta9.srv.hcvlny.cv.net [167.206.5.133])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 3818A19980
> 	for <9fans@cse.psu.edu>; Tue,  9 Jul 2002 11:40:44 -0400 (EDT)
> Received: from dave2.dave.tj (ool-4351482a.dyn.optonline.net [67.81.72.42])
>  by mta9.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 (built Feb 21 2002))
>  with ESMTP id <0GYZ00D3UMV2XY@mta9.srv.hcvlny.cv.net> for 9fans@cse.psu.edu;
>  Tue, 09 Jul 2002 11:25:50 -0400 (EDT)
> Received: (from dave@localhost)	by dave2.dave.tj (8.10.2/8.10.2)
>  id g69FTj832499	for 9fans@cse.psu.edu; Tue, 09 Jul 2002 15:29:45 +0000 (GMT)
> From: Dave <dave@dave.tj>
> Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
> In-reply-to: <adc08ee0f9815311c935f3784f2ed48f@plan9.escet.urjc.es> from
>  <Fco.J.Ballesteros@Jul>
> To: 9fans@cse.psu.edu
> Message-id: <200207091529.g69FTj832499@dave2.dave.tj>
> MIME-version: 1.0
> X-Mailer: ELM [version 2.5 PL3]
> Content-type: text/plain; charset=iso-8859-1
> Content-transfer-encoding: 8BIT
> Sender: 9fans-admin@cse.psu.edu
> Errors-To: 9fans-admin@cse.psu.edu
> X-BeenThere: 9fans@cse.psu.edu
> X-Mailman-Version: 2.0.11
> Precedence: bulk
> Reply-To: 9fans@cse.psu.edu
> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
> Date: Tue, 09 Jul 2002 11:29:45 -0400 (EDT)
> 
> AFAIK, VFAT uses Unicode for its long file names, so I see no reason
> why ␣ shouldn't be allowed there.
> 
>  - Dave
> 
> 
> Fco.J.Ballesteros wrote:
> > 
> > : Wrong!  What if files 'a b' and 'a_b' both exist on the foreign
> > : system?  Back to the drawing board, everyone, the problem needs
> > : another, slightly more focussed iteration.
> > 
> > I'm renaming ' ' with ␣ in u9fs
> > There's no problem doing that since there's no ␣
> > in outside file names.
> > 
> 
> --upas-gyhymjcadgjxkouzirlpoqbniv--
> 

Re: [9fans] blanks in file names

[Dave]

You're missing the point: With the changes I propose to our kernel,
certain programs will be able to have much simpler logic.  In addition to
undoing the changes in the kernel, you'd have to rewrite the "offending"
program - only manual recoding can accomplish that.

 - Dave


Fco.J.Ballesteros wrote:
> 
> This is a multi-part message in MIME format.
> --upas-xuojoahyqverhjcrtrjsvosjtu
> Content-Disposition: inline
> Content-Type: text/plain; charset="US-ASCII"
> Content-Transfer-Encoding: 7bit
> 
> Really, I make changes now and then; many times after
> trying the resulting binaries I change my mind and
> use yesterday + cp to restore the source back to its
> previous state. Some other times I bind temporary directories
> on top of the sources and make the changes there.
> 
> 
> --upas-xuojoahyqverhjcrtrjsvosjtu
> Content-Type: message/rfc822
> Content-Disposition: inline
> 
> Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Tue Jul  9 17:22:23 MDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id E683A19A1C; Tue,  9 Jul 2002 11:22:09 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.5.4])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 437E71998C
> 	for <9fans@cse.psu.edu>; Tue,  9 Jul 2002 11:21:03 -0400 (EDT)
> Received: from dave2.dave.tj (ool-4351482a.dyn.optonline.net [67.81.72.42])
>  by mta1.srv.hcvlny.cv.net
>  (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002))
>  with ESMTP id <0GYZ00FXXMNYMH@mta1.srv.hcvlny.cv.net> for 9fans@cse.psu.edu;
>  Tue, 09 Jul 2002 11:21:34 -0400 (EDT)
> Received: (from dave@localhost)	by dave2.dave.tj (8.10.2/8.10.2)
>  id g69FNP431828	for 9fans@cse.psu.edu; Tue, 09 Jul 2002 15:23:25 +0000 (GMT)
> From: Dave <dave@dave.tj>
> Subject: Re: [9fans] blanks in file names
> In-reply-to: <c55e55e304beec4b477c71af7fa9c712@plan9.escet.urjc.es> from
>  <Fco.J.Ballesteros@Jul>
> To: 9fans@cse.psu.edu
> Message-id: <200207091523.g69FNP431828@dave2.dave.tj>
> MIME-version: 1.0
> X-Mailer: ELM [version 2.5 PL3]
> Content-type: text/plain; charset=us-ascii
> Content-transfer-encoding: 7BIT
> Sender: 9fans-admin@cse.psu.edu
> Errors-To: 9fans-admin@cse.psu.edu
> X-BeenThere: 9fans@cse.psu.edu
> X-Mailman-Version: 2.0.11
> Precedence: bulk
> Reply-To: 9fans@cse.psu.edu
> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
> Date: Tue, 09 Jul 2002 11:23:25 -0400 (EDT)
> 
> You're not going to do that every time you make a change to the
> filesystem.  Besides, that won't undo all the "changes" to all the
> new programs that lack complexity because they don't have to reinvent
> the wheel.
> 
>  - Dave
> 
> 
> Fco.J.Ballesteros wrote:
> > 
> > >> But above all, I will undo the changes made in this respect to my
> > >> local system if you guys or the system designers choose a different way.
> > ...
> > > Undoing kernel-level changes won't be easy, especially when people start
> > 
> > 9fs dump
> > cp blah blah
> > 
> > Sorry, couldn't resist. I just love this system :-)
> > 
> 
> --upas-xuojoahyqverhjcrtrjsvosjtu--
> 

Re: [9fans] blanks in file names

[FJ Ballesteros]

Dave ha escrito:
> 
> You're missing the point: With the changes I propose to our kernel,
> certain programs will be able to have much simpler logic.  In addition to
> undoing the changes in the kernel, you'd have to rewrite the "offending"
> program - only manual recoding can accomplish that.
> 

No offending program if there's no native ' ' in file names. Just
have to cope with those still seen from the outside world.
I have a working trfs that deals with most cases here (still will miss
names
inside files). I'll send it tomorrow.

Changing open just because of this would mean to rethink many tools
and nobody knows (because there's no experience with your proposed
system)
if it would introduce other problems. So I'd vote no.

Re: [9fans] blanks in file names

[Dave]

The "offending" program in this case is the program that's so much simpler
because it's using the new kernel interface rather than the old one.

Nothing has to be rethought because all my proposed changes do is restore
the strict seperation between nodes in a filename (something UNIX -
and therefore Plan 9 - likes to rely on).

There's plenty of experience with other systems working on linked lists
(including a huge amount of kernel code in my Linux box that I'm typing
from, ATM).  Most of the problems with linked lists have been pretty
well documented, by now.

 - Dave



FJ Ballesteros wrote:
> 
> 
> 
> Dave ha escrito:
> > 
> > You're missing the point: With the changes I propose to our kernel,
> > certain programs will be able to have much simpler logic.  In addition to
> > undoing the changes in the kernel, you'd have to rewrite the "offending"
> > program - only manual recoding can accomplish that.
> > 
> 
> No offending program if there's no native ' ' in file names. Just
> have to cope with those still seen from the outside world.
> I have a working trfs that deals with most cases here (still will miss
> names
> inside files). I'll send it tomorrow.
> 
> Changing open just because of this would mean to rethink many tools
> and nobody knows (because there's no experience with your proposed
> system)
> if it would introduce other problems. So I'd vote no.
> 

Re: [9fans] blanks in file names

[Dan Cross]

> The "offending" program in this case is the program that's so much simpler
> because it's using the new kernel interface rather than the old one.

I don't think it would be simpler; I think it would be more
complicated.  You're replacing a simple, textual representation of an
object with a binary representation; you have to have some way to do
canonicalization in the common case, but even that path is thrwat with
danger.

> Nothing has to be rethought because all my proposed changes do is restore
> the strict seperation between nodes in a filename (something UNIX -
> and therefore Plan 9 - likes to rely on).

But they change an already well-established interface.  Have you
thought through the implications of this, in all their macabre glory?
What you propose--changing the most basic interface for opening a file
in a system where everything looks more or less like a file--has huge
implications.  And all this just to support a strange edge-case, which
is adequately solved by substitutions in the filename.  Sure, it's not
perfect in some weird pathological case, but how often is this going to
come up in practice?  Remember: Optimize for the common case.

> There's plenty of experience with other systems working on linked lists
> (including a huge amount of kernel code in my Linux box that I'm typing
> from, ATM).  Most of the problems with linked lists have been pretty
> well documented, by now.

It's the huge amount of kernel code that Plan 9 is trying to avoid.

Being forced to conform to a lot of external interfaces *will* kill the
system.

Besides, the point Nemo was trying to make umpteen posts ago was that,
yes, you can roll back changes using the dump filesystem, which gives
you temporal mobility.  He is right.

	- Dan C.

Re: [9fans] blanks in file names

[Dave]

Reply inline:

 - Dave

Dan Cross wrote:
> 
> > The "offending" program in this case is the program that's so much simpler
> > because it's using the new kernel interface rather than the old one.
> 
> I don't think it would be simpler; I think it would be more
> complicated.  You're replacing a simple, textual representation of an
> object with a binary representation; you have to have some way to do
> canonicalization in the common case, but even that path is thrwat with
> danger.
Manipulating text with all sorts of dynamic buffers is substantially
more complicated than simply replacing a node in a linked list.
The canonicalization is all being done by the kernel, or a library.

> 
> > Nothing has to be rethought because all my proposed changes do is restore
> > the strict seperation between nodes in a filename (something UNIX -
> > and therefore Plan 9 - likes to rely on).
> 
> But they change an already well-established interface.  Have you
> thought through the implications of this, in all their macabre glory?
> What you propose--changing the most basic interface for opening a file
> in a system where everything looks more or less like a file--has huge
> implications.  And all this just to support a strange edge-case, which
> is adequately solved by substitutions in the filename.  Sure, it's not
> perfect in some weird pathological case, but how often is this going to
> come up in practice?  Remember: Optimize for the common case.
Optimization for the common case is good, but creating a system where the
uncommon case will cause major mayhem at the system level is evidence
of a very unclean approach.  (When you consider the reasoning behind
the problem (namely, spaces and slashes in filenames kill our ability
to seperate nodes easily), it makes perfect sense that our solution
isn't very clean.  The only clean solution is to restore the ancient
UNIX ideal of being able to easily seperate nodes.  In other words,
either kill spaces altogether and damn interoperability, or promote
spaces to full citizenship.)

> 
> > There's plenty of experience with other systems working on linked lists
> > (including a huge amount of kernel code in my Linux box that I'm typing
> > from, ATM).  Most of the problems with linked lists have been pretty
> > well documented, by now.
> 
> It's the huge amount of kernel code that Plan 9 is trying to avoid.
String manipulation is more complex than linked list manipulation.

> 
> Being forced to conform to a lot of external interfaces *will* kill the
> system.
I don't dispute that point, but the interface I propose is most unlike
any other interface currently known to man (not trying to conform to any
external interface).  I'm simply pointing out that failing to provide
at least a 1-1 mapping with capabilities that are already widely used
in external systems that must interoperate with ours *will* kill us.

> 
> Besides, the point Nemo was trying to make umpteen posts ago was that,
> yes, you can roll back changes using the dump filesystem, which gives
> you temporal mobility.  He is right.
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 why
automation is a good thing.  The worst part about our system is that the
"solution" you eventually find for an FTP mirror will be useless on an
HTTP proxy.  When "solutions" need to be modified for each individual
application, you know that the system isn't clean.

> 
> 	- Dan C.
> 
 - Dave C. :-)

Re: [9fans] blanks in file names

[Dan Cross]

> > I don't think it would be simpler; I think it would be more
> > complicated.  You're replacing a simple, textual representation of an
> > object with a binary representation; you have to have some way to do
> > canonicalization in the common case, but even that path is thrwat with
> > danger.
> 
> Manipulating text with all sorts of dynamic buffers is substantially
> more complicated than simply replacing a node in a linked list.
> The canonicalization is all being done by the kernel, or a library.

How could this possibly be in the kernel?  After all, you're talking
about changing the interface to open a file; I pass a file name via
some mechanism to a user level application that wants to call open on
it.  What's it supposed to do?  Does the shell now pass a linked list
as an argument to main somehow?  How does the system know that it's a
file?  Do we have to replace the argument vector with some more complex
representation that encapsulates type information (e.g., this argument
is a file, this next one is a string, etc)?  Does the shell change to
represent file names as lists?  Does the user suffer the indignation of
having to specify a list of path components to represent a file?  Or do
we provide a canonicalization library for shell arguments, in which
case, you have the exact same problem as supporting spaces now, since
most programs are going to expect to get file name arguments in the
canonical representation?  If you do that, who calls it?  The shell or
the library?

I for one am going to be *very* unhappy if I have to type:

	cat ('' 'usr' 'cross' 'file')

Instead of:

	cat /usr/cross/file

Or do you make every program that wants to open a file call a function
to canonicalize a filename into the internal format before it calls
open?

> > But they change an already well-established interface.  Have you
> > thought through the implications of this, in all their macabre glory?
> > What you propose--changing the most basic interface for opening a file
> > in a system where everything looks more or less like a file--has huge
> > implications.  And all this just to support a strange edge-case, which
> > is adequately solved by substitutions in the filename.  Sure, it's not
> > perfect in some weird pathological case, but how often is this going to
> > come up in practice?  Remember: Optimize for the common case.
> 
> Optimization for the common case is good, but creating a system where the
> uncommon case will cause major mayhem at the system level is evidence
> of a very unclean approach.  (When you consider the reasoning behind
> the problem (namely, spaces and slashes in filenames kill our ability
> to seperate nodes easily), it makes perfect sense that our solution
> isn't very clean.  The only clean solution is to restore the ancient
> UNIX ideal of being able to easily seperate nodes.  In other words,
> either kill spaces altogether and damn interoperability, or promote
> spaces to full citizenship.)

But Plan 9 can handle this.

One of the beautiful things about Plan 9 is that it provides a solution
that's workable with little effort.  The various substitution file
systems provide a workable solution without introducing any additional
complexity.  If you want a total--100% complete--solution, then a
`urlifyfs' can be written that uses URL escaping as a canonical
representation, or something similar.  The system interface doesn't
have to be changed, though.  *That* is the mark of a clean system
design.

The Unix `ideal' was eliminated because it was overly complex, without
a commensurate gain in functionality.  Besides, the inode system didn't
really fit in well with the idea of 9p.

> > > There's plenty of experience with other systems working on linked lists
> > > (including a huge amount of kernel code in my Linux box that I'm typing
> > > from, ATM).  Most of the problems with linked lists have been pretty
> > > well documented, by now.
> > 
> > It's the huge amount of kernel code that Plan 9 is trying to avoid.
> 
> String manipulation is more complex than linked list manipulation.

No, it's really not.  Consider passing a linked list as an argument to
a function you're calling, versus passing an argument vector of
strings.  How do you do that?  Do you muck with all the C startup code
to make sure you get the linking and so right in such a way that the
list is in a contiguous memory block so it doesn't get stomped by the
image read by exec?  Do you pass each node in the list to main as a
seperate string in the argument vector?  If so, how do you tell when
a file name ends and another begins?  Do we introduce some convention
for delineating the beginning and ends of a filename in a list
representation, effectively creating a protocol that every program has
to follow to take a filename as an argument?  Surely the former option
is significantly easier....

Consider a possible canonicalization routine that might be used in
a substitution FS:

char *
canonical(char *str)
{
	char	*p, *s, *t;
 
	if (str == nil || (p = malloc(2 * strlen(str) + 1)) == nil) {
		return(nil);
	}
	for (s = str, t = p; *s != '\0'; s++, t++) {
		if (isspace(*s)) {
			*t++ = '+';	/*  Or whatever.  */
			*t = '2';
			continue;
		}
		*t = *s;
	}
	if ((s = realloc(p, strlen(p) + 1)) == nil) {
		free(p);
	}
 
	return(s);
}

That's pretty straight-forward; just inserting into a linked list
would be just as hard.  Doing so in a contiguous memory block would
be, I think harder (you'd have to step over the list, keep a count
of how much memory you needed, then allocate the list, copy each
node and set the links.  That's a pain).

> > Being forced to conform to a lot of external interfaces *will* kill the
> > system.
> 
> I don't dispute that point, but the interface I propose is most unlike
> any other interface currently known to man (not trying to conform to any
> external interface).  I'm simply pointing out that failing to provide
> at least a 1-1 mapping with capabilities that are already widely used
> in external systems that must interoperate with ours *will* kill us.

Well, if you *really* want 100% 1 to 1 mappings, use the URL encoding
others have mentioned, or something similar.  As it is, it seems that
this mostly works; about 80% of what's needed is there.

> > Besides, the point Nemo was trying to make umpteen posts ago was that,
> > yes, you can roll back changes using the dump filesystem, which gives
> > you temporal mobility.  He is right.
> 
> 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 why
> automation is a good thing.  The worst part about our system is that the
> "solution" you eventually find for an FTP mirror will be useless on an
> HTTP proxy.  When "solutions" need to be modified for each individual
> application, you know that the system isn't clean.

Yesterday is a wonderful tool, and can be scripted to do whatever you
want.  Eg, copying all files that changed on June 14th back to the
cache isn't very diffcult.

I don't see what running a big FTP mirror has to do with it.  netlib is
a big FTP site; it runs on Plan 9.  Maybe it's not a mirror, but so what?
I also don't see how you can't leverage whatever you did for FTP with
HTTP.  The substitution-style FS gives you a *lot* of flexibility in this
area.

	- Dan C.

Re: [9fans] blanks in file names

[Dave]

Reply inline:

 - Dave

Dan Cross wrote:
> 
> > > I don't think it would be simpler; I think it would be more
> > > complicated.  You're replacing a simple, textual representation of an
> > > object with a binary representation; you have to have some way to do
> > > canonicalization in the common case, but even that path is thrwat with
> > > danger.
> > 
> > Manipulating text with all sorts of dynamic buffers is substantially
> > more complicated than simply replacing a node in a linked list.
> > The canonicalization is all being done by the kernel, or a library.
> 
> How could this possibly be in the kernel?  After all, you're talking
> about changing the interface to open a file; I pass a file name via
> some mechanism to a user level application that wants to call open on
> it.  What's it supposed to do?  Does the shell now pass a linked list
> as an argument to main somehow?  How does the system know that it's a
> file?  Do we have to replace the argument vector with some more complex
> representation that encapsulates type information (e.g., this argument
> is a file, this next one is a string, etc)?  Does the shell change to
> represent file names as lists?  Does the user suffer the indignation of
> having to specify a list of path components to represent a file?  Or do
> we provide a canonicalization library for shell arguments, in which
> case, you have the exact same problem as supporting spaces now, since
> most programs are going to expect to get file name arguments in the
> canonical representation?  If you do that, who calls it?  The shell or
> the library?
That's an interesting point I didn't quite consider ... we'll have to
change the exec interface a lot more than I suspected at first glance.
I wasn't planning that until much later, because it'll require very
fundamental changes to the shell.  (/me hates proposing incremental
changes, because they invariably depend on other fundamental changes in
order for people to see their utility.)

> 
> I for one am going to be *very* unhappy if I have to type:
> 
> 	cat ('' 'usr' 'cross' 'file')
> 
> Instead of:
> 
> 	cat /usr/cross/file
> 
> Or do you make every program that wants to open a file call a function
> to canonicalize a filename into the internal format before it calls
> open?
My image of a shell is a user interface.  It should translate
all output from programs into a format that's easy for a human to
understand, and should offer to translate data entered by the user
from an easy-for-a-human-to-input format into the machine format.
If you want to print /"usr"/"cross"/"file", you should be able to
type something like "cat /usr/cross/file" and have the shell translate
that into the collection of lists (/usr/bin/cat and /usr/cross/file)
required for the underlying system.  The shell should also translate
the output of the ls command, for instance, so it prints filenames
in an easy-for-humans-to-understand format.  The ls command, though,
should only print filenames in an easy-for-machine-to-understand
format.  Basically, the shell is the bidirectional translator between
computer-speak and human-speak.  That's it's raison d'étre (spelling?).
Getting the kernel away from plain text doesn't mean getting the shell
away from plain text.  The shell can choose to support any method(s)
it wants to represent filenames in an "easy-for-machine-to-understand"
format, since it'll be converting the filenames into linked lists for
the kernel.  Utilities like find or ls or whatever output filenames in
a format that your shell can read.  (I envision an rc file supplied by
the shell to let other programs know what formats it supports.)

> 
> > > But they change an already well-established interface.  Have you
> > > thought through the implications of this, in all their macabre glory?
> > > What you propose--changing the most basic interface for opening a file
> > > in a system where everything looks more or less like a file--has huge
> > > implications.  And all this just to support a strange edge-case, which
> > > is adequately solved by substitutions in the filename.  Sure, it's not
> > > perfect in some weird pathological case, but how often is this going to
> > > come up in practice?  Remember: Optimize for the common case.
> > 
> > Optimization for the common case is good, but creating a system where the
> > uncommon case will cause major mayhem at the system level is evidence
> > of a very unclean approach.  (When you consider the reasoning behind
> > the problem (namely, spaces and slashes in filenames kill our ability
> > to seperate nodes easily), it makes perfect sense that our solution
> > isn't very clean.  The only clean solution is to restore the ancient
> > UNIX ideal of being able to easily seperate nodes.  In other words,
> > either kill spaces altogether and damn interoperability, or promote
> > spaces to full citizenship.)
> 
> But Plan 9 can handle this.
> 
> One of the beautiful things about Plan 9 is that it provides a solution
> that's workable with little effort.  The various substitution file
> systems provide a workable solution without introducing any additional
> complexity.  If you want a total--100% complete--solution, then a
> `urlifyfs' can be written that uses URL escaping as a canonical
> representation, or something similar.  The system interface doesn't
> have to be changed, though.  *That* is the mark of a clean system
> design.
The only way to have the urlifyfs concept providing a 100% complete
solution is to use it as the default filesystem for your own stuff.
The reason?  imagine downloading a file "blah%apos;" from an FTP server;
now, you download a file "blah'" from an FTP server (which your urlifyfs
faithfully translates into "blah%apos;" without realizing that it's
destroying a different file).  Guess what?  You've just clobbered your
original.  Now, if you're going to use urlifyfs for your own stuff
on your Plan 9 system, you're going to have to deal with the same
shell-interaction issues that my system has to deal with.  The only
difference is that my system doesn't break if somebody forgets to use
urlifyfs on a new filesystem, because my system moves text representation
of filenames over to the shell, where it belongs, rather than dumping
that burden on a filesystem translation hack.

> 
> The Unix `ideal' was eliminated because it was overly complex, without
> a commensurate gain in functionality.  Besides, the inode system didn't
> really fit in well with the idea of 9p.
> 
> > > > There's plenty of experience with other systems working on linked lists
> > > > (including a huge amount of kernel code in my Linux box that I'm typing
> > > > from, ATM).  Most of the problems with linked lists have been pretty
> > > > well documented, by now.
> > > 
> > > It's the huge amount of kernel code that Plan 9 is trying to avoid.
> > 
> > String manipulation is more complex than linked list manipulation.
> 
> No, it's really not.  Consider passing a linked list as an argument to
> a function you're calling, versus passing an argument vector of
> strings.  How do you do that?  Do you muck with all the C startup code
> to make sure you get the linking and so right in such a way that the
> list is in a contiguous memory block so it doesn't get stomped by the
> image read by exec?  Do you pass each node in the list to main as a
> seperate string in the argument vector?  If so, how do you tell when
> a file name ends and another begins?  Do we introduce some convention
> for delineating the beginning and ends of a filename in a list
> representation, effectively creating a protocol that every program has
> to follow to take a filename as an argument?  Surely the former option
> is significantly easier....
This is only true with our current exec family, which has been essentially
carried over unchanged from UNIX.  It's based on strings, not on lists.
IMHO, arguments should be objects.  Those objects can be filenames,
options with or without arguments of their own, subcommands, just plain
strings, etc.  This makes arguments a lot more representitive of what
they actually are, and eliminates the need for complex argument-handling
libraries.  Obviously, this whole change can be totally transparent to
the user, because his shell is doing the necessary translations back
and forth.  However, you get an extremely powerful system as the payoff,
a system that makes it rather easy to reimplement all our current syscalls
as tiny library functions, possibly in an emulation library.

> 
> Consider a possible canonicalization routine that might be used in
> a substitution FS:
> 
> char *
> canonical(char *str)
> {
> 	char	*p, *s, *t;
>  
> 	if (str == nil || (p = malloc(2 * strlen(str) + 1)) == nil) {
> 		return(nil);
> 	}
> 	for (s = str, t = p; *s != '\0'; s++, t++) {
> 		if (isspace(*s)) {
> 			*t++ = '+';	/*  Or whatever.  */
> 			*t = '2';
> 			continue;
> 		}
> 		*t = *s;
> 	}
> 	if ((s = realloc(p, strlen(p) + 1)) == nil) {
> 		free(p);
> 	}
>  
> 	return(s);
> }
> 
> That's pretty straight-forward; just inserting into a linked list
> would be just as hard.  Doing so in a contiguous memory block would
> be, I think harder (you'd have to step over the list, keep a count
> of how much memory you needed, then allocate the list, copy each
> node and set the links.  That's a pain).
strlen() is an expensive operation.  realloc() sucks in a multithreaded
environment.  To top it all off, that algorithm doesn't take into account
the expansion which is ABSOLUTELY NECESSARY in order to achieve 100%
coverage.  (If you're not going to achieve a 1-1 mapping, it's silly to
even bother with this.)  Also, I'd like to mention again that I'm not
asking the kernel to allocate memory.  The userland program provides
a block of memory, and the kernel manipulates that block, returning an
error if the block is too small.

> 
> > > Being forced to conform to a lot of external interfaces *will* kill the
> > > system.
> > 
> > I don't dispute that point, but the interface I propose is most unlike
> > any other interface currently known to man (not trying to conform to any
> > external interface).  I'm simply pointing out that failing to provide
> > at least a 1-1 mapping with capabilities that are already widely used
> > in external systems that must interoperate with ours *will* kill us.
> 
> Well, if you *really* want 100% 1 to 1 mappings, use the URL encoding
> others have mentioned, or something similar.  As it is, it seems that
> this mostly works; about 80% of what's needed is there.
URL encoding _will_ work if it's implemented right (except for the
uncleanliness I mentioned above, and some more problems I mention below).
However, using URL encoding makes the resulting system just as ugly as
the one I'm proposing from the user's perspective, but much much uglier
from a system perspective.

> 
> > > Besides, the point Nemo was trying to make umpteen posts ago was that,
> > > yes, you can roll back changes using the dump filesystem, which gives
> > > you temporal mobility.  He is right.
> > 
> > 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 why
> > automation is a good thing.  The worst part about our system is that the
> > "solution" you eventually find for an FTP mirror will be useless on an
> > HTTP proxy.  When "solutions" need to be modified for each individual
> > application, you know that the system isn't clean.
> 
> Yesterday is a wonderful tool, and can be scripted to do whatever you
> want.  Eg, copying all files that changed on June 14th back to the
> cache isn't very diffcult.
Yesterday can't be used to update the relative references in all the
README files in the FTP archives to the urlified versions.

> 
> I don't see what running a big FTP mirror has to do with it.  netlib is
> a big FTP site; it runs on Plan 9.  Maybe it's not a mirror, but so what?
Since it's not a mirror, it doesn't have to contend with all the spaceful
filenames you find in the non-Plan9 world.

> I also don't see how you can't leverage whatever you did for FTP with
> HTTP.  The substitution-style FS gives you a *lot* of flexibility in this
> area.
What you did in FTP was scanning the README files for references.
What you do in HTTP is updating all the href and src attributes in HTML
files (and hope none of the JAVA programs have embedded URLs that you
can't change at all), so you don't get broken links everywhere.

...unless you want to implement the transformation/detransformation
code in the FTP and HTTP servers, as well ... in which case your
system becomes one step worse than my system, because you have
transformation/detransformation code in two places on your system :-(

> 
> 	- Dan C.
> 

Re: [9fans] blanks in file names

[Lucio De Re]

On Thu, Jul 11, 2002 at 02:14:59AM -0400, Dave wrote:
> 
> Reply inline:
> 
You make some valid points, but I think they are well in excess of
present requirements.  Not to say that a future OS/GUI will not (have
to) take them into consideration.

You do however confuse URI and HTML and you really shouldn't:


> The only way to have the urlifyfs concept providing a 100% complete
> solution is to use it as the default filesystem for your own stuff.
> The reason?  imagine downloading a file "blah%apos;" from an FTP server;
> now, you download a file "blah'" from an FTP server (which your urlifyfs
> faithfully translates into "blah%apos;" without realizing that it's
> destroying a different file).  Guess what?  You've just clobbered your
> original.  Now, if you're going to use urlifyfs for your own stuff

URI: blah%apos; -> blah%25pos%3b

++L

Re: [9fans] blanks in file names

[Dave]

Lucio De Re wrote:
> 
> On Thu, Jul 11, 2002 at 02:14:59AM -0400, Dave wrote:
> > 
> > Reply inline:
> > 
> You make some valid points, but I think they are well in excess of
> present requirements.  Not to say that a future OS/GUI will not (have
> to) take them into consideration.
Okay, fair enough ... I'll just wait a few more years until some OS
agrees to go out on a limb with me (Release 5, maybe?) ;-)

> 
> You do however confuse URI and HTML and you really shouldn't:
> 
> 
> > The only way to have the urlifyfs concept providing a 100% complete
> > solution is to use it as the default filesystem for your own stuff.
> > The reason?  imagine downloading a file "blah%apos;" from an FTP server;
> > now, you download a file "blah'" from an FTP server (which your urlifyfs
> > faithfully translates into "blah%apos;" without realizing that it's
> > destroying a different file).  Guess what?  You've just clobbered your
> > original.  Now, if you're going to use urlifyfs for your own stuff
> 
> URI: blah%apos; -> blah%25pos%3b
Whoopsies ... my brain must've been half mush when I typed that :-(

> 
> ++L
> 

Re: [9fans] blanks in file names

[arisawa]

Hello,

> One of the beautiful things about Plan 9 is that it provides a  
solution
> that's workable with little effort.  The various substitution file
> systems provide a workable solution without introducing any  
additional
> complexity.  If you want a total--100% complete--solution, then a
> `urlifyfs' can be written that uses URL escaping as a canonical
> representation, or something similar.  The system interface  
doesn't
> have to be changed, though.  *That* is the mark of a clean system
> design.
The idea was born from the discussion between Dave and I.
Dave proposed '\' escape.
Until that time, I had been tied to quoting strategy.
%XX looks ugly as Dave says, but it works cleanly.
That is the beauty.
We must be patient with this ugliness because we are in textual
environment. Full GUI environment, I believe Plan9 also have it
in future, will remove this ugliness.
Thanks Dave.

Kenji Arisawa

Re: [9fans] blanks in file names

[arisawa]

Hello,

I should have added to my previous thread:
I think `urlifyfs' or similar stuff is good idea.
I didn't have that idea.

Kenji Arisawa

Re: [9fans] blanks in file names

[Dan Cross]

I want to let this thread die, but I just have one last thing to say:

> Getting the kernel away from plain text doesn't mean getting the shell

But....  It took 20 years to get the kernel to plain text.  I don't want
to go back.

	- Dan C.

Re: [9fans] blanks in file names

[Ish Rattan]

Probably it is time for this thread to go away.

An OS design is a reflection of what the designer considers
important -- who gives a hoot if it not a clean design. My
response: if you do not like it either desgin your "own" OR
use one that you consider a clean OS!!

-ishwar

On Wed, 10 Jul 2002, Dave wrote:

> Reply inline:
>
>  - Dave
>
> Dan Cross wrote:
> >
> > > The "offending" program in this case is the program that's so much simpler
> > > because it's using the new kernel interface rather than the old one.
> >
> > I don't think it would be simpler; I think it would be more
> > complicated.  You're replacing a simple, textual representation of an
> > object with a binary representation; you have to have some way to do
> > canonicalization in the common case, but even that path is thrwat with
> > danger.
> Manipulating text with all sorts of dynamic buffers is substantially
> more complicated than simply replacing a node in a linked list.
> The canonicalization is all being done by the kernel, or a library.
>
> >
> > > Nothing has to be rethought because all my proposed changes do is restore
> > > the strict seperation between nodes in a filename (something UNIX -
> > > and therefore Plan 9 - likes to rely on).
> >
> > But they change an already well-established interface.  Have you
> > thought through the implications of this, in all their macabre glory?
> > What you propose--changing the most basic interface for opening a file
> > in a system where everything looks more or less like a file--has huge
> > implications.  And all this just to support a strange edge-case, which
> > is adequately solved by substitutions in the filename.  Sure, it's not
> > perfect in some weird pathological case, but how often is this going to
> > come up in practice?  Remember: Optimize for the common case.
> Optimization for the common case is good, but creating a system where the
> uncommon case will cause major mayhem at the system level is evidence
> of a very unclean approach.  (When you consider the reasoning behind
> the problem (namely, spaces and slashes in filenames kill our ability
> to seperate nodes easily), it makes perfect sense that our solution
> isn't very clean.  The only clean solution is to restore the ancient
> UNIX ideal of being able to easily seperate nodes.  In other words,
> either kill spaces altogether and damn interoperability, or promote
> spaces to full citizenship.)
>
> >
> > > There's plenty of experience with other systems working on linked lists
> > > (including a huge amount of kernel code in my Linux box that I'm typing
> > > from, ATM).  Most of the problems with linked lists have been pretty
> > > well documented, by now.
> >
> > It's the huge amount of kernel code that Plan 9 is trying to avoid.
> String manipulation is more complex than linked list manipulation.
>
> >
> > Being forced to conform to a lot of external interfaces *will* kill the
> > system.
> I don't dispute that point, but the interface I propose is most unlike
> any other interface currently known to man (not trying to conform to any
> external interface).  I'm simply pointing out that failing to provide
> at least a 1-1 mapping with capabilities that are already widely used
> in external systems that must interoperate with ours *will* kill us.
>
> >
> > Besides, the point Nemo was trying to make umpteen posts ago was that,
> > yes, you can roll back changes using the dump filesystem, which gives
> > you temporal mobility.  He is right.
> 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 why
> automation is a good thing.  The worst part about our system is that the
> "solution" you eventually find for an FTP mirror will be useless on an
> HTTP proxy.  When "solutions" need to be modified for each individual
> application, you know that the system isn't clean.
>
> >
> > 	- Dan C.
> >
>  - Dave C. :-)
>

Re: [9fans] blanks in file names

[Dave]

Okay, I think we might have enough votes to finally kill the thread ;-)

 - Dave


Ish Rattan wrote:
> 
> Probably it is time for this thread to go away.
> 
> An OS design is a reflection of what the designer considers
> important -- who gives a hoot if it not a clean design. My
> response: if you do not like it either desgin your "own" OR
> use one that you consider a clean OS!!
> 
> -ishwar
> 
> On Wed, 10 Jul 2002, Dave wrote:
> 
> > Reply inline:
> >
> >  - Dave
> >
> > Dan Cross wrote:
> > >
> > > > The "offending" program in this case is the program that's so much simpler
> > > > because it's using the new kernel interface rather than the old one.
> > >
> > > I don't think it would be simpler; I think it would be more
> > > complicated.  You're replacing a simple, textual representation of an
> > > object with a binary representation; you have to have some way to do
> > > canonicalization in the common case, but even that path is thrwat with
> > > danger.
> > Manipulating text with all sorts of dynamic buffers is substantially
> > more complicated than simply replacing a node in a linked list.
> > The canonicalization is all being done by the kernel, or a library.
> >
> > >
> > > > Nothing has to be rethought because all my proposed changes do is restore
> > > > the strict seperation between nodes in a filename (something UNIX -
> > > > and therefore Plan 9 - likes to rely on).
> > >
> > > But they change an already well-established interface.  Have you
> > > thought through the implications of this, in all their macabre glory?
> > > What you propose--changing the most basic interface for opening a file
> > > in a system where everything looks more or less like a file--has huge
> > > implications.  And all this just to support a strange edge-case, which
> > > is adequately solved by substitutions in the filename.  Sure, it's not
> > > perfect in some weird pathological case, but how often is this going to
> > > come up in practice?  Remember: Optimize for the common case.
> > Optimization for the common case is good, but creating a system where the
> > uncommon case will cause major mayhem at the system level is evidence
> > of a very unclean approach.  (When you consider the reasoning behind
> > the problem (namely, spaces and slashes in filenames kill our ability
> > to seperate nodes easily), it makes perfect sense that our solution
> > isn't very clean.  The only clean solution is to restore the ancient
> > UNIX ideal of being able to easily seperate nodes.  In other words,
> > either kill spaces altogether and damn interoperability, or promote
> > spaces to full citizenship.)
> >
> > >
> > > > There's plenty of experience with other systems working on linked lists
> > > > (including a huge amount of kernel code in my Linux box that I'm typing
> > > > from, ATM).  Most of the problems with linked lists have been pretty
> > > > well documented, by now.
> > >
> > > It's the huge amount of kernel code that Plan 9 is trying to avoid.
> > String manipulation is more complex than linked list manipulation.
> >
> > >
> > > Being forced to conform to a lot of external interfaces *will* kill the
> > > system.
> > I don't dispute that point, but the interface I propose is most unlike
> > any other interface currently known to man (not trying to conform to any
> > external interface).  I'm simply pointing out that failing to provide
> > at least a 1-1 mapping with capabilities that are already widely used
> > in external systems that must interoperate with ours *will* kill us.
> >
> > >
> > > Besides, the point Nemo was trying to make umpteen posts ago was that,
> > > yes, you can roll back changes using the dump filesystem, which gives
> > > you temporal mobility.  He is right.
> > 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 why
> > automation is a good thing.  The worst part about our system is that the
> > "solution" you eventually find for an FTP mirror will be useless on an
> > HTTP proxy.  When "solutions" need to be modified for each individual
> > application, you know that the system isn't clean.
> >
> > >
> > > 	- Dan C.
> > >
> >  - Dave C. :-)
> >
> 

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Fco.J.Ballesteros]

: Wrong!  What if files 'a b' and 'a_b' both exist on the foreign
: system?  Back to the drawing board, everyone, the problem needs
: another, slightly more focussed iteration.

I'm renaming ' ' with ␣ in u9fs
There's no problem doing that since there's no ␣
in outside file names.

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Lucio De Re]

On Tue, Jul 09, 2002 at 10:42:04AM +0200, Fco.J.Ballesteros wrote:
> 
> I'm renaming ' ' with ? in u9fs
> There's no problem doing that since there's no ?
> in outside file names.

There could be:

-rw-r--r--   1 lucio  staff         0 Jul  9 11:22 t?uch

produced by "touch t\?uch" on my NetBSD host.  This is from
"man 2 intro" on NetBSD 1.5.2:

     File Name
             Names consisting of up to 255 (MAXNAMELEN) characters may be used
             to name an ordinary file, special file, or directory.

             These characters may be selected from the set of all ASCII char-
             acter excluding 0 (NUL) and the ASCII code for `/' (slash).  (The
             parity bit, bit 7, must be 0.)

             Note that it is generally unwise to use `*', `?', `[' or `]' as
             part of file names because of the special meaning attached to
             these characters by the shell.

It needn't be up to date, but it's a safe indicator.

++L

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[andrey mirtchovski]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1490 bytes --]

umm,

were you reading this from a unix machine? i think nemo meant that he's
replacing ' ' with a non-ascii rune in p9 (maybe your font
mistranslated it to '?' in the terminal?)...

here's what the original looked like:

I'm renaming ' ' with â^У in u9fs
There's no problem doing that since there's no â^У
in outside file names.

andrey (who thinks nemo's solution looks quite ok)

On Tue, 9 Jul 2002, Lucio De Re wrote:

> On Tue, Jul 09, 2002 at 10:42:04AM +0200, Fco.J.Ballesteros wrote:
> >
> > I'm renaming ' ' with ? in u9fs
> > There's no problem doing that since there's no ?
> > in outside file names.
>
> There could be:
>
> -rw-r--r--   1 lucio  staff         0 Jul  9 11:22 t?uch
>
> produced by "touch t\?uch" on my NetBSD host.  This is from
> "man 2 intro" on NetBSD 1.5.2:
>
>      File Name
>              Names consisting of up to 255 (MAXNAMELEN) characters may be used
>              to name an ordinary file, special file, or directory.
>
>              These characters may be selected from the set of all ASCII char-
>              acter excluding 0 (NUL) and the ASCII code for `/' (slash).  (The
>              parity bit, bit 7, must be 0.)
>
>              Note that it is generally unwise to use `*', `?', `[' or `]' as
>              part of file names because of the special meaning attached to
>              these characters by the shell.
>
> It needn't be up to date, but it's a safe indicator.
>
> ++L
>

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[matt]

>I'm renaming ' ' with â^У in u9fs
>There's no problem doing that since there's no â^У
>in outside file names.

can't see them either but "there is no" could possibly become "oops now
there is"?

Re: [9fans] acme question + diffs for kfs, fs and plumbing

[Fco.J.Ballesteros]

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

There's no reason.
I though of using ☺, but I think it's more
usual in file names than ␣.

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

From: Dave <dave@dave.tj>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Tue, 09 Jul 2002 11:29:45 -0400 (EDT)
Message-ID: <200207091529.g69FTj832499@dave2.dave.tj>

AFAIK, VFAT uses Unicode for its long file names, so I see no reason
why ␣ shouldn't be allowed there.

 - Dave


Fco.J.Ballesteros wrote:
> 
> : Wrong!  What if files 'a b' and 'a_b' both exist on the foreign
> : system?  Back to the drawing board, everyone, the problem needs
> : another, slightly more focussed iteration.
> 
> I'm renaming ' ' with ␣ in u9fs
> There's no problem doing that since there's no ␣
> in outside file names.
> 

Re: [9fans] blanks in file names

[Fco.J.Ballesteros]

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

Really, I make changes now and then; many times after
trying the resulting binaries I change my mind and
use yesterday + cp to restore the source back to its
previous state. Some other times I bind temporary directories
on top of the sources and make the changes there.


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

From: Dave <dave@dave.tj>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] blanks in file names
Date: Tue, 09 Jul 2002 11:23:25 -0400 (EDT)
Message-ID: <200207091523.g69FNP431828@dave2.dave.tj>

You're not going to do that every time you make a change to the
filesystem.  Besides, that won't undo all the "changes" to all the
new programs that lack complexity because they don't have to reinvent
the wheel.

 - Dave


Fco.J.Ballesteros wrote:
> 
> >> But above all, I will undo the changes made in this respect to my
> >> local system if you guys or the system designers choose a different way.
> ...
> > Undoing kernel-level changes won't be easy, especially when people start
> 
> 9fs dump
> cp blah blah
> 
> Sorry, couldn't resist. I just love this system :-)
> 

Re: [9fans] blanks in file names

[David Gordon Hogan]

Isn't this thread dead yet?

Re: [9fans] blanks in file names

[arisawa]

>Isn't this thread dead yet?
It seems ...
So I asked: Is it important?
So I said: My preference is just s/ /_/g
So I proposed: uq (unquote)
Any way, I dislike ' ' in file name.

Kenji Arisawa