Re: [9fans] spaces in filenames

Re: [9fans] spaces in filenames

[Russ Cox]

looks like you pulled in a big one, geoff.
where do you get such great lures?

[9fans] lures

[Michael Baldwin]

yeah, that's what i like about geoff.  if you can't have animated
discussions of such fringe stuff as cursor keys vs. mouse or spaces in
filenames on 9fans, then it would be a duller world.

Re: [9fans] lures

[Lucio De Re]

On Sat, Jun 01, 2002 at 10:34:13AM -0400, Michael Baldwin wrote:
>
> yeah, that's what i like about geoff.  if you can't have animated
> discussions of such fringe stuff as cursor keys vs. mouse or spaces in
> filenames on 9fans, then it would be a duller world.

The clincher is that the space is useful both as a separator of
command line arguments and as a joiner of filename "words".  Seeing
as even Micahel Baldwin does not suggest using spaces as path
separators (why not?) I would be tempted to go along with the school
of thought that proposes using a teeny dot in filenames.

The rationale being that long filenames, GUIs and Internationalisation
are all the _new_ rage and may as well be lumped into a single
paradigm change.

That we should need a keyboard key for the new pseudospace (it was
very useful in Wang Word Processors, others may remember it from
MultiMate days) in as convenient a position as the present space
bar, well, that is a little harder to address.

Also, I think it was dhog suggesting proportional spacing fonts in
program source (I shudder!) but in my mind a diminutive dot would
look nice as a linking space in the proportional space representation
of a long file name.

Finally, the space as a command line argument separator could be
sacrificed, but the result would not be aesthetically pleasing, in
my opinion.  And the diminutive dot would look wrong in this context,
specially if using a proportional font.

To give Michael his due, spaces in filenames can no longer be
suppressed.  But if they become very common, it will become more
convenient to use a GUI than command line composition.  That will
be a sad day.

++L

PS:  It's tempting to dig up the arguments in favour of Oberon's flat
filespace, I wonder how it would be received by the proponents of a
namespace _based_ on file paths :-)

[9fans] spaces, separators, and utf-8

[Michael Baldwin]

On Saturday, June 1, 2002, at 10:59 , lucio@proxima.alt.za wrote:

> The clincher is that the space is useful both as a separator of
> command line arguments and as a joiner of filename "words".

command line arguments can be trivially quoted.  if the issue is
possible shell misinterpretation, then we've got a whole slew of allowed
chars that are "problems": * ? ; < > [ ] { } ` ' " $ & ^ # = \ |.  they
are all allowed now, and if i type them at a shell, i've got to quote
them.  one shell (mash) used : as a special char, and there were and are
files with colons in them in the plan 9 distribution.  so why does space
get all the scorn?

> Seeing as even Michael Baldwin does not suggest using spaces as path
> separators (why not?)

["even Michael Baldwin" -- are you saying i now have a reputation as a
communist?!]

we already have a separator (/), no need for another one.  or are you
asking why not space instead?  when i call a file "My Great Novel" it
doesn't seem natural to think of space as a path separator.  i used
Primos eons ago, and they used ">", which is perhaps arguably slightly
more intuitive than "/" (or ":" or "\").  i can imagine wanting to put a
date in a filename as in 2002/06/01 or use / in other ways in names,
but > is harder to imagine.

but in the end, you must have a separator, so you just pick a char and
say it's the separator.  it is /.  and you cannot use / otherwise in a
path.  fine, that's life.  and 9P even works when accessing something
that doesn't use / because the protocol itself doesn't use / in Twalk.
so one can even get to those ugly \ systems from plan 9 (until they do
something stupid like put / in a path element).  but space as a path
separator?  yikes, no.

but speaking to digy's point, i'm glad that control chars are
disallowed.  i think it is useful to have a char or two that you know
are outside the possible charset for filenames.  i'm thinking of \t and
\n, which can easily be used in text programs to delimit paths if they
don't feel like quoting.  and NUL, well let's not get started.  does NUL
work *anywhere*?  can't use it in C strings, can't use it in acme or rio
or sam, can't use it in old 9P.  curiously enough, 9P2000 can actually
transport it.  but just say no to NUL.

> The rationale being that long filenames, GUIs and Internationalisation
> are all the _new_ rage and may as well be lumped into a single
> paradigm change.

hmm, i thought that internationalization by using utf-8 everywhere
(including in pathnames) was pioneered by plan 9 itself.  and it is a
good idea.  mac os x uses utf-8 paths and does ok with utf-8 in terminal
windows and mail; what about the other unixoid systems?  but are there
any systems that handle utf-8 as cleanly as plan 9 yet?  i don't know of
any.  the mac has problems (do ls in a Terminal window, or use TextEdit
or [gasp] vi or emacs), and if there is a convenient input method, i
haven't found it.  now it would be a great thing if this attribute of
plan 9 (utf-8 everywhere and it just works, decent C language support,
and a goodly-sized unicode font) were put into the commercial OS's out
there.  hey geoff, can you pull that off at apple?  certainly you
wouldn't be opposed to *that* crusade?!

[9fans] long path names

[Michael Baldwin]

now that long names are really supported in plan 9, when is the archive
format going to be fixed?  it still uses the 16-char limit from the
ancient days, which even 3rd edition plan 9 could choke on (16 < 28).
other systems out there use one of i think 3 different hacks to extend
the name limit (ugh).

Re: [9fans] spaces, separators, and utf-8

[Scott Schwartz]

| ...  and 9P even works when accessing something
| that doesn't use / because the protocol itself doesn't use / in Twalk.
| so one can even get to those ugly \ systems from plan 9 (until they do
| something stupid like put / in a path element).

If open took an array of filenames, you wouldn't need a delimiter in the
kernel.  On the other hand, if there were system calls that gave more
direct access to 9p, you could do it that way.  An old thread also argued
for that on the grounds of making stacked file servers easier to build.

| don't feel like quoting.  and NUL, well let's not get started.  does NUL
| work *anywhere*?

It is said to work in TCL, where they use a (technically illegal)
utf sequence that translates to 0x0000.

Re: [9fans] spaces, separators, and utf-8

[Dan Cross]

> ["even Michael Baldwin" -- are you saying i now have a reputation as a
> communist?!]

Yes.

	- Dan C.

:-)