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

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

[rob pike, esq.]

You don't want blanks in native files, I promise you.  The kfs changes
(at least) are ill-advised.

-rob

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] 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] 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] 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

[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

[Fco.J.Ballesteros]

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

The rune I was talking about is "open box, visible space"
(0x2423) I'm sorry, but I thought all of us could accept utf mails. 
If there's ever such a rune being used in outside
systems, you can always pick a different one (still unused).

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

From: "matt" <matt@proweb.co.uk>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Tue, 9 Jul 2002 13:05:30 +0100
Message-ID: <022201c22740$ecbec270$6501a8c0@xpire>

>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

[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

[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]

> 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

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

[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

[Fco.J.Ballesteros]

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

It's ok if the name contains '?', it's just inconvenient but
it's ok. It's like that inconvenient "'chk" name I had.

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

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Tue, 9 Jul 2002 11:28:57 +0200
Message-ID: <20020709112856.L20312@cackle.proxima.alt.za>

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

[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

[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]

>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

[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

[Fco.J.Ballesteros]

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

Yes, but did an undo and will never redo it.
Had enough blanks for the rest of my life.

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

From: arisawa@ar.aichi-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Tue,  9 Jul 2002 17:22:03 +0900
Message-ID: <20020709082218.AB50B199EE@mail.cse.psu.edu>

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] 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] 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

[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

[Fco.J.Ballesteros]

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

Just to clarify, I'm no longer pursuing blanks on Plan 9.
As a matter of fact, I never liked them. Now that I'm happy
to see that Rob does not want them on native files I can just
rename them in u9fs.

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

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Tue, 9 Jul 2002 09:38:32 +0900
Message-ID: <20020709003915.580A719991@mail.cse.psu.edu>

>I would just like an acme window to be able to hold
>"/a/b x/d/e/f x"

Why, nemo, are you so eager to permit blank as a file name?
Does it come from European language nature?
IMHO:  our language, yes Japanese has no such blank as a delimiter
of words, so I have no such interest to that.  :-)

Kenji

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

[okamoto]

>I would just like an acme window to be able to hold
>"/a/b x/d/e/f x"

Why, nemo, are you so eager to permit blank as a file name?
Does it come from European language nature?
IMHO:  our language, yes Japanese has no such blank as a delimiter
of words, so I have no such interest to that.  :-)

Kenji

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

[arisawa]

>...not even ... if you s/ /_/g all incoming filenames, you'll have  
no
>way of distinguishing 'a b' from 'a_b' ... or am I wrong?
> - Dave
You misunderstand something.
We need not distinguishing 'a b' from 'a_b' because there are
no files that contains ' ' in their names.

Kenji Arisawa

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

[Dave]

...not even ... if you s/ /_/g all incoming filenames, you'll have no
way of distinguishing 'a b' from 'a_b' ... or am I wrong?

 - Dave


rob pike, esq. wrote:
> 
> This is a multi-part message in MIME format.
> --upas-hysbwqswxskaflauqaypshypxy
> Content-Disposition: inline
> Content-Type: text/plain; charset="US-ASCII"
> Content-Transfer-Encoding: 7bit
> 
> 99% only.  You'd still have the problem of names that arrive surreptitiously,
> such as in tar files.
> 
> -rob
> 
> --upas-hysbwqswxskaflauqaypshypxy
> Content-Type: message/rfc822
> Content-Disposition: inline
> 
> Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Jul  8 12:06:16 EDT 2002
> Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Jul  8 12:06:15 EDT 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 7F994199BC; Mon,  8 Jul 2002 12:06:08 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from nautilus.escet.urjc.es (nautilus.escet.urjc.es [212.128.4.207])
> 	by mail.cse.psu.edu (CSE Mail Server) with SMTP id C8D81199B9
> 	for <9fans@cse.psu.edu>; Mon,  8 Jul 2002 12:05:05 -0400 (EDT)
> Message-ID: <8aeb5e383c12f6b44b043e969d203fb5@plan9.escet.urjc.es>
> From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> 	boundary="upas-gtvahntgehtrsxxskbyfbulvvm"
> 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: Mon, 8 Jul 2002 18:05:03 +0200
> 
> This is a multi-part message in MIME format.
> --upas-gtvahntgehtrsxxskbyfbulvvm
> Content-Disposition: inline
> Content-Type: text/plain; charset="US-ASCII"
> Content-Transfer-Encoding: 7bit
> 
> Renaming them would get us quickly up to 100%, with no need
> to fix anything. Am I wrong?
> --upas-gtvahntgehtrsxxskbyfbulvvm
> Content-Type: message/rfc822
> Content-Disposition: inline
> 
> Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Mon Jul  8 18:01:23 MDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id 1D95B19995; Mon,  8 Jul 2002 12:01:13 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from plan9.cs.bell-labs.com (ampl.com [204.178.31.2])
> 	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 7A9F519991
> 	for <9fans@cse.psu.edu>; Mon,  8 Jul 2002 12:00:11 -0400 (EDT)
> Message-ID: <a5b373bbdc70b762911c083da046ca5f@plan9.bell-labs.com>
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
> From: "rob pike, esq." <rob@plan9.bell-labs.com>
> MIME-Version: 1.0
> 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: Mon, 8 Jul 2002 12:00:09 -0400
> 
> > Glub! My first view of all this blank thing was just to forbid
> > them and maybe rename them just to avoid them (They make things more
> > complex for our programs). 
> 
> I encounter a dozen blank-containing names a day, but only from
> interacting with foreign systems.  I find the current setup covers about
> 80% of what I need; fixing a few other simple things would probably
> get us to 99%.  But upon reflection I don't think it's wise to push for
> blanks to be first-class citizens in file names.  As long as we continue
> to use linguistic rather than graphical interfaces to most of our tools,
> that would be a mistake.
> 
> -rob
> 
> --upas-gtvahntgehtrsxxskbyfbulvvm--
> --upas-hysbwqswxskaflauqaypshypxy--
> 

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

[rob pike, esq.]

> 99% only.  You'd still have the problem of names that arrive surreptitiously,
> such as in tar files.

Expanding a bit....

This is why I decided (mea maxima culpa) to admit blanks in file names.
They show up, you don't know where from, and if the basic tools have
ways of coping (as opposed to being graceful and perfect in handling them)
you can get by without mystery error messages caused by the operating
system rejecting them deep down.

I think the setup is sufficient, and sufficient unto the day is the evil thereof.

-rob

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

[rob pike, esq.]

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

99% only.  You'd still have the problem of names that arrive surreptitiously,
such as in tar files.

-rob

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

[-- Attachment #2.1.1: Type: text/plain, Size: 89 bytes --]

Renaming them would get us quickly up to 100%, with no need
to fix anything. Am I wrong?

[-- Attachment #2.1.2: Type: message/rfc822, Size: 1779 bytes --]

From: "rob pike, esq." <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Mon, 8 Jul 2002 12:00:09 -0400
Message-ID: <a5b373bbdc70b762911c083da046ca5f@plan9.bell-labs.com>

> Glub! My first view of all this blank thing was just to forbid
> them and maybe rename them just to avoid them (They make things more
> complex for our programs). 

I encounter a dozen blank-containing names a day, but only from
interacting with foreign systems.  I find the current setup covers about
80% of what I need; fixing a few other simple things would probably
get us to 99%.  But upon reflection I don't think it's wise to push for
blanks to be first-class citizens in file names.  As long as we continue
to use linguistic rather than graphical interfaces to most of our tools,
that would be a mistake.

-rob

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

[Fco.J.Ballesteros]

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

Renaming them would get us quickly up to 100%, with no need
to fix anything. Am I wrong?

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

From: "rob pike, esq." <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Mon, 8 Jul 2002 12:00:09 -0400
Message-ID: <a5b373bbdc70b762911c083da046ca5f@plan9.bell-labs.com>

> Glub! My first view of all this blank thing was just to forbid
> them and maybe rename them just to avoid them (They make things more
> complex for our programs). 

I encounter a dozen blank-containing names a day, but only from
interacting with foreign systems.  I find the current setup covers about
80% of what I need; fixing a few other simple things would probably
get us to 99%.  But upon reflection I don't think it's wise to push for
blanks to be first-class citizens in file names.  As long as we continue
to use linguistic rather than graphical interfaces to most of our tools,
that would be a mistake.

-rob

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

[rob pike, esq.]

> Glub! My first view of all this blank thing was just to forbid
> them and maybe rename them just to avoid them (They make things more
> complex for our programs). 

I encounter a dozen blank-containing names a day, but only from
interacting with foreign systems.  I find the current setup covers about
80% of what I need; fixing a few other simple things would probably
get us to 99%.  But upon reflection I don't think it's wise to push for
blanks to be first-class citizens in file names.  As long as we continue
to use linguistic rather than graphical interfaces to most of our tools,
that would be a mistake.

-rob

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

[Fco.J.Ballesteros]

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

Glub! My first view of all this blank thing was just to forbid
them and maybe rename them just to avoid them (They make things more
complex for our programs). 

But then I (mis)understood that the plan for the system was to give
them a chance; thus I tried to find a simple way to get them working.

Now that I finally see that the agreement is on 
`blanks would mess up things', I think I'll just add them to isfrog and
rename them in u9fs (the only place were I get blanks into the system).

Thanks for your answer and sorry about the mess.

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

From: "rob pike, esq." <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Mon, 8 Jul 2002 11:42:05 -0400
Message-ID: <7b9a9eaaf34e6773065104024b7696c2@plan9.bell-labs.com>

> So all the effort to handle ' ' was just for foreign files?

Yes.  And that is the main reason I don't want to trash the
system to support blanks in file names.

-rob

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

[rob pike, esq.]

> So all the effort to handle ' ' was just for foreign files?

Yes.  And that is the main reason I don't want to trash the
system to support blanks in file names.

-rob

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

[Fco.J.Ballesteros]

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

So all the effort to handle ' ' was just for foreign files?

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

From: "rob pike, esq." <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme question + diffs for kfs, fs and plumbing
Date: Mon, 8 Jul 2002 11:16:57 -0400
Message-ID: <53a4b2914a2d14090c0f2bc46f48ce8a@plan9.bell-labs.com>

You don't want blanks in native files, I promise you.  The kfs changes
(at least) are ill-advised.

-rob

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

[Lucio De Re]

On Mon, Jul 08, 2002 at 05:10:00PM +0200, Fco.J.Ballesteros wrote:
> 
> ??
> 
> I would just like an acme window to be able to hold
> "/a/b x/d/e/f x"
> in its tag line. Currently, it would stop at the first
> blank and eat the rest of the file name. I'm not talking
> about metacharacters.
> 
> I think that a couple of changes in wind.c could do the effect.

It would seem more consistent, in the tag _name_ to use quoting
<duck!>.

I was thinking of presenting the above as /a/b?x/d/e/f?x, but I wasn't
considering the tag name, I was thinking of a specification in the tag
tail.

++L

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

[Fco.J.Ballesteros]

> I'm not familiar with ACME's innards, but wouldn't it be more
> consistent to have ACME understand the "?" wild character in the
> tag?  Of course this has other drawbacks, but it strikes me as a good
> starting point for discussion.

??

I would just like an acme window to be able to hold
"/a/b x/d/e/f x"
in its tag line. Currently, it would stop at the first
blank and eat the rest of the file name. I'm not talking
about metacharacters.

I think that a couple of changes in wind.c could do the effect.

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

[Lucio De Re]

On Mon, Jul 08, 2002 at 04:54:24PM +0200, Fco.J.Ballesteros wrote:
> 
> Could we change the acme tag so that the file name is terminated by
> `|' and not by space?  Otherwise I don't know how to let acme edit
> files that have blanks on their names (It would eat part of the name).
> 
I'm not familiar with ACME's innards, but wouldn't it be more
consistent to have ACME understand the "?" wild character in the
tag?  Of course this has other drawbacks, but it strikes me as a good
starting point for discussion.

++L

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

[Fco.J.Ballesteros]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1113 bytes --]

Could we change the acme tag so that the file name is terminated by
`|' and not by space?  Otherwise I don't know how to let acme edit
files that have blanks on their names (It would eat part of the name).


Now the diffs. I had to make them to let my system handle
blanks on file names; i.e. to
	- let the plumber config know of blanks
	- permit blanks in kfs
	- permit blanks in fs
	- permit blanks in acme tags (I don't include this one).

/sys/lib/plumb/basic:
	- add space as a valid char for file names.
	  eg. '[ a-zA-Z¡-￿0-9_\-./]+' instead of '[ a-zA-Z¡-￿0-9_\-./]+'


Permit blanks in kfs servers:

diff /n/dump/2002/0708/sys/src/cmd/disk/kfs/sub.c sub.c
382c382
< 		if(c <= 040)
---
> 		if(c < 040)
diff /n/dump/2002/0708/sys/src/cmd/disk/kfs/9p2.c 9p2.c
795c795
< 		if((*p & 0xFF) <= 040)
---
> 		if((*p & 0xFF) < 040)

Permit blanks in real file servers:

diff ./port/9p2.c /sys/src/fs/port/9p2.c
155c155
< 		if((*p & 0xFF) <= 040)
---
> 		if((*p & 0xFF) < 040)
diff ./port/sub.c /sys/src/fs/port/sub.c
496c496
< 		if(c <= 040)
---
> 		if(c < 040)