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?!

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.

:-)

[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).

[9fans] spaces in filenames

[smiley]

Hi,

>From time to time, the issue of having spaces in file names seems to
come up on this list, mostly in the context of discussions on find, du,
Acme, and trfs(4).  All the discussions I've found suggest that file
names with whitespace in them are *legal* on fossil.  I'm running a
9atom 9pcf kernel copied verbatim from the 9atom .iso, on an otherwise
stock Plan 9 4e fossil+venti install.  However, I can't seem to create
files with with spaces in their names.  The resulting error string
reports invalid characters in the file name.  Why doesn't this work?
Has the ability to have spaces in file names been removed from fossil?
If so, then how is it possible that there are files such as
'/n/sources/contrib/steve/file with spaces' hanging around?

While I'm perfectly happy using underscores in lieu of spaces in *my*
file names, there are a number of APE packages (i.e., fgb/lcms)
containing files with spaces in their names.  Since those are the names
used in replica(1), I'm unable to contrib/install(1) any of these
packages.  Are there any known fixes or workarounds for this problem?
(I doubt trfs(4) would help, because the ape would still be naming the
file with spaces, unless specifically modified to match the trfs(4)
translation.)

What's the theory behind excluding whitespace from filenames?  Was it
causing too much discussion on the list?  ;) Since Plan 9 was a total
re-think of Unix, I have to wonder why this problem wasn't fixed.  If
Plan 9 used 0x00 (NUL) as the record separator (instead of newline),
many of these types of problems could be averted.  Why don't we?

Also, if anyone knows where I can find 9fans archives prior to March
2008, please let me know.  The archives I was able to find only go back
that far.

Also, quanstro, would you whitelist me?  I can't seem to get mail to you
off-list.  Thanks!

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] spaces in filenames

[Rob Pike]

Sometime around, maybe, 2000, I flipped the bit in the frogs table so
spaces were legal in file names, for two reasons: we were seeing
spaces in file names from remote systems and seemed simpler to accept
them than to remap them, and I wanted to know how it would affect
things.

Not all software has caught up, I suspect.  It's only been a decade.

-rob

Re: [9fans] spaces in filenames

[erik quanstrom]

>
> Not all software has caught up, I suspect.  It's only been a decade.
>

my software hasn't.  i'm just a philistine.

- erik

Re: [9fans] spaces in filenames

[dexen deVries]

On Tuesday 26 of April 2011 20:42:49 Rob Pike wrote:
> Sometime around, maybe, 2000, I flipped the bit in the frogs table so
> spaces were legal in file names, for two reasons: we were seeing
> spaces in file names from remote systems and seemed simpler to accept
> them than to remap them, and I wanted to know how it would affect
> things.
>
> Not all software has caught up, I suspect.  It's only been a decade.


on the topic, is acme still your favorite editor, Rob?
asking, cause it is mine, and about the only thing i miss in it is sensible
support for whitespace in pathnames. i'm using the p9p version, btw.


--
dexen deVries

``One can't proceed from the informal to the formal by formal means.''

Re: [9fans] spaces in filenames

[Rob Pike]

I still use acme.  My solution for spaces in file names is to avoid
them.  That might not work for everyone.

-rob

Re: [9fans] spaces in filenames

[Paul Lalonde]

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

I mostly run acme from inferno (acme-SAC), and live with trfs to take care
of my windows and mac paths.  My linux paths are much better behaved, and so
I run from p9p there.

Paul

On Tue, Apr 26, 2011 at 12:31 PM, Rob Pike <robpike@gmail.com> wrote:

> I still use acme.  My solution for spaces in file names is to avoid
> them.  That might not work for everyone.
>
> -rob
>
>


--
I'm migrating my email.  plalonde@telus.net will soon be disconnected.
 Please use paul.a.lalonde@gmail.com from now on.

[-- Attachment #2: Type: text/html, Size: 982 bytes --]

Re: [9fans] spaces in filenames

[Digby Tarvin]

I was always happy with the traditional Unix approach - Kernel allows
anything unless there is a good reason not to (ie no NULL or '/').
Anything else is an application problem that usually required
some ingenuity if you really wanted to break convention.

But then, I have never been a big fan of spaces in filenames so
varying levels of support in userland was not a big concern.

I can remember amusing myself once as an undergraduate, deleting and
creating files till I got the right inode numbers to allow a judicious
choice of binary file names to result in a directory that was a
valid executable a.out image.

DigbyT
--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] spaces in filenames

[erik quanstrom]

On Wed Apr 27 09:12:15 EDT 2011, digbyt@acm.org wrote:
> I was always happy with the traditional Unix approach - Kernel allows
> anything unless there is a good reason not to (ie no NULL or '/').
> Anything else is an application problem that usually required
> some ingenuity if you really wanted to break convention.

port/chan.c:/^char isfrog

- erik

Re: [9fans] spaces in filenames

[Steve Simon]

> I can remember amusing myself once as an undergraduate, deleting and
> creating files till I got the right inode numbers to allow a judicious
> choice of binary file names to result in a directory that was a
> valid executable a.out image.

Wonderful!

This made me laugh loud enough to make everyone in the office turn round.

-Steve

Re: [9fans] spaces in filenames

[Peter A. Cejchan]

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

spaces in filenames.. does not it break the rules?? Who actually needs
them??

++pac

[-- Attachment #2: Type: text/html, Size: 100 bytes --]

Re: [9fans] spaces in filenames

[erik quanstrom]

>  From time to time, the issue of having spaces in file names seems to
> come up on this list, mostly in the context of discussions on find,
> du, Acme, and trfs(4).  All the discussions I've found suggest that
> file names with whitespace in them are *legal* on fossil.  I'm running
> a 9atom 9pcf kernel copied verbatim from the 9atom .iso, on an
> otherwise stock Plan 9 4e fossil+venti install.  However, I can't seem
> to create files with with spaces in their names.  The resulting error
> string reports invalid characters in the file name.  Why doesn't this
> work?  Has the ability to have spaces in file names been removed from
> fossil?  If so, then how is it possible that there are files such as
> '/n/sources/contrib/steve/file with spaces' hanging around?

this is all my fault.

ken fs doesn't allow spaces in file names, and neither does kfs.
since many scripts tend to do the wrong thing with such file names,
i thought it would be a lot easier to just disallow them, and deal
with any problems that come up at file creation time, instead of
when you're running a script that's mysteriously failing.

the sources version of fossil does allow spaces in filenames.

> While I'm perfectly happy using underscores in lieu of spaces in *my*
> file names, there are a number of APE packages (i.e., fgb/lcms)
> containing files with spaces in their names.  Since those are the
> names used in replica(1), I'm unable to contrib/install(1) any of
> these packages.  Are there any known fixes or workarounds for this
> problem?  (I doubt trfs(4) would help, because the ape would still be
> naming the file with spaces, unless specifically modified to match the
> trfs(4) translation.)

i have never run into this.  my preferred solution would be to fix
the contrib packages, but that's not my call.

sorry for the inconvienece.

> Also, if anyone knows where I can find 9fans archives prior to March
> 2008, please let me know.  The archives I was able to find only go
> back that far.

http://9fans.net/archive

> Also, quanstro, would you whitelist me?  I can't seem to get mail to
> you off-list.  Thanks!

done.

- erik

Re: [9fans] spaces in filenames

[smiley]

erik quanstrom <quanstro@quanstro.net> writes:

> the sources version of fossil does allow spaces in filenames.

I'm hypothesizing that my version of fossil isn't allowing spaces in
file names because the version compiled into the '#//boot/boot/fossil'
in the 9atom 9pcf kernel from the 9atom .iso doesn't allow spaces.
Would that hypothesis be correct?  (Which would bring me to my next
question: how to recompile the 9atom kernel, with _tracein and _traceout
undefined in the final link and all, but that's a topic for a different
thread.)

> i have never run into this.  my preferred solution would be to fix
> the contrib packages, but that's not my call.

:( It's not mine, either.

> http://9fans.net/archive

Yes, I found that.  However, if there's an API for downloading them,
it's not obvious.  Short of spidering 9fans.net, is there a place to get
them?

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] spaces in filenames

[erik quanstrom]

On Tue Apr 26 22:34:26 EDT 2011, smiley@zenzebra.mv.com wrote:
> erik quanstrom <quanstro@quanstro.net> writes:
>
> > the sources version of fossil does allow spaces in filenames.
>
> I'm hypothesizing that my version of fossil isn't allowing spaces in
> file names because the version compiled into the '#//boot/boot/fossil'
> in the 9atom 9pcf kernel from the 9atom .iso doesn't allow spaces.
> Would that hypothesis be correct?  (Which would bring me to my next
> question: how to recompile the 9atom kernel, with _tracein and _traceout
> undefined in the final link and all, but that's a topic for a different
> thread.)

i hope to clean all this junk up in my infinite spare time.  sorry.

rebuild libc after adding this, or remove the flags section from your
/sys/src/9/pc/9pcf*.

; cat /sys/src/libc//386/trace.s
TEXT _tracein(SB), 1, $0
	CMPL	traceactive(SB), $0
	JEQ	inotready
	MOVL	16(SP),AX
	PUSHL	AX
	MOVL	16(SP),AX
	PUSHL	AX
	MOVL	16(SP),AX
	PUSHL	AX
	MOVL	16(SP),AX
	PUSHL	AX
	MOVL	16(SP),AX
	PUSHL	AX
	CALL	tracein(SB)
	POPL	AX
	POPL	AX
	POPL	AX
	POPL	AX
	POPL	AX
inotready:
	RET

TEXT _traceout(SB), 1, $0
	CMPL	traceactive(SB), $0
	JEQ	notready
	PUSHL	AX
	MOVL	4(SP),AX
	PUSHL	AX
	CALL	traceout(SB)
	POPL	AX
	POPL	AX
notready:
	RET

- erik

Re: [9fans] spaces in filenames

[presotto]

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

YOu can't read and write from user level a file descriptor that has
already been mounted.  Otherwise, you could side step authentication
to file servers.

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

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] spaces in filenames
Date: Mon, 03 Jun 2002 12:06:35 +0200
Message-ID: <200206031006.g53A6ZI15198@zamenhof.cs.utwente.nl>

> > I can bypass the kernel easily enough:
>
> man 9pcon

cpu% aux/9pcon /srv/dns
read9pmsg from server: inappropriate use of fd
cpu%

What does that error message mean?
Did I invoke 9pcon in the wrong way?

Axel.

Re: [9fans] spaces in filenames

[Russ Cox]

> I can bypass the kernel easily enough:

man 9pcon

Re: [9fans] spaces in filenames

[William Josephson]

On Sat, Jun 01, 2002 at 06:17:09PM -0400, Russ Cox wrote:
> > I can bypass the kernel easily enough:
>
> man 9pcon

I'm aware of it, but last I checked it didn't
compile on FreeBSD :-p

Re: [9fans] spaces in filenames

[Axel Belinfante]

> > I can bypass the kernel easily enough:
>
> man 9pcon

cpu% aux/9pcon /srv/dns
read9pmsg from server: inappropriate use of fd
cpu%

What does that error message mean?
Did I invoke 9pcon in the wrong way?

Axel.

Re: [9fans] spaces in filenames

[Russ Cox]

> Sorry, I should have said: this was on a 3rd edition kfs.

The bug is still there in the 4e kfs binary I am running.
I am just very confused as to why.

Russ

Re: [9fans] spaces in filenames

[Richard Miller]

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

> Anyhow, you didn't misunderstand the syntax.
> That should have worked.  That's how the
> install moves your old file system into /3e.

Sorry, I should have said: this was on a 3rd edition kfs.

-- Richard


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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] spaces in filenames
Date: Sat, 1 Jun 2002 10:01:43 -0400
Message-ID: <ecb4d092e6486a09039ef6b51f86ee42@plan9.bell-labs.com>

> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
>
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
>
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?

That's one of the first Plan 9 mistakes I ever made.
I killed off the partition and started afresh.  (Not the right answer.)

Anyhow, you didn't misunderstand the syntax.
That should have worked.  That's how the
install moves your old file system into /3e.
The case where src and dst are in same
directory must use the wrong name.

Russ

Re: [9fans] spaces in filenames

[Russ Cox]

> Anyhow, you didn't misunderstand the syntax.
> That should have worked.  That's how the
> install moves your old file system into /3e.
> The case where src and dst are in same
> directory must use the wrong name.

I have no idea why this doesn't work.  I'm staring
at the rename code and it really should work.
Unless I misunderstand what nextelem does.

You'll note that

	disk/kfscmd 'rename /tmp/yyy a/b/c/d'

correctly diagnoses the fact that there are slashes
in the new name.  Destinations beginning with /
are supposed to do what you expect.

I'm leaving for a trip soon, but will be online
with reasonable frequency.  If someone else
wants to add the appropriate print, figure out
what's wrong, and send me a fix, I'd be happy to
put it in.

Russ

Re: [9fans] spaces in filenames

[Russ Cox]

> hmm ... disk/kfscmd 'rename /tmp/\/tmp\/yyy yyy'?

you expect far too much from kfs.

Re: [9fans] spaces in filenames

[Russ Cox]

> You should be able to rename it again; maybe you'll need to rename
> it in to another directory if there is a bug.

BZZT!  How do you rename it?  When you pass
the path to kfs or the kernel, it will tokenize
it into

	'tmp' 'xxx' 'tmp' 'yyy'

instead of

	'tmp' 'xxx' '/tmp/yyy'

as is necessary.

Re: [9fans] spaces in filenames

[William Josephson]

On Sat, Jun 01, 2002 at 10:10:18AM -0400, Russ Cox wrote:
> > You should be able to rename it again; maybe you'll need to rename
> > it in to another directory if there is a bug.
>
> BZZT!  How do you rename it?  When you pass
> the path to kfs or the kernel, it will tokenize

Forgot that kfs will parse the path, too.
I can bypass the kernel easily enough: I
wrote a stupid 9p shell after I broke some
names on the fileserver by untarring
something on a 9p2k terminal.  Guess it is
time to do some hacking...

Re: [9fans] spaces in filenames

[Russ Cox]

> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
>
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
>
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?

That's one of the first Plan 9 mistakes I ever made.
I killed off the partition and started afresh.  (Not the right answer.)

Anyhow, you didn't misunderstand the syntax.
That should have worked.  That's how the
install moves your old file system into /3e.
The case where src and dst are in same
directory must use the wrong name.

Russ

Re: [9fans] spaces in filenames

[Richard Miller]

I got myself into trouble recently by misunderstanding the syntax
of the kfs 'rename' command.  If you do something like

  disk/kfscmd 'rename /tmp/xxx /tmp/yyy'

you end up with a file in /tmp with slashes in its name.  Exercise
for the reader: how do you get rid of it?

-- Richard

Re: [9fans] spaces in filenames

[William Josephson]

On Sat, Jun 01, 2002 at 02:55:47PM +0000, Richard Miller wrote:
> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
>
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
>
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?

You should be able to rename it again; maybe you'll need to rename
it in to another directory if there is a bug.

Re: [9fans] spaces in filenames

[Sam]

> On Sat, Jun 01, 2002 at 02:55:47PM +0000, Richard Miller wrote:
> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
>
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
>
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?
>

hmm ... disk/kfscmd 'rename /tmp/\/tmp\/yyy yyy'?

Re: [9fans] spaces in filenames

[Geoff Collyer]

Okay, you're a communist.  ☺

On Unix, part of the problem is scripts that use $* when they should
use "$@", but the need to quote file names containing spaces
interactively is an on-going nuisance.

If you're going to allow spaces, then why not allow tabs?  They have
traditionally been considered equivalent whitespace, with a few
exceptions (e.g., make, tbl).  I don't see a compelling reason to
allow spaces but not tabs.  And if you allow spaces and tabs, why not
newline, it's whitespace too.  And as long as we're allowing any old
character in file names, why not allow slashes in file name
components?  Sure, we'll have to introduce some ugly hack like having
the kernel understand /this\/is\/all\/one\/component, but by now we're
not afraid of a little quoting, right?  And why discriminate against
NUL?  Shouldn't one be able to have a file name like 'This is a
history of the \0, \\ and \/ characters in computing, © 2002 <a
href="http:\/\/pedant.com\/peter.jpg">Peter Pedant<\/a>', where \0
represents a NUL byte?

We could also adopt another Mac OS tradition, case-insensitive file
names.  Pretty soon our file names will be as ungodly a stew as
anything ever parsed by MVS or VMS.

Re: [9fans] spaces in filenames

[Michael Baldwin]

> On Unix, part of the problem is scripts that use $* when they should
> use "$@"

yeah, so fix them, if it's so easy.  are there lots of these around?  i
haven't noticed.

> but the need to quote file names containing spaces interactively is an
> on-going nuisance.

i guess if you think 'quoting' is a nuisance.  yes, you have to quote
spaces in shell args.  i also have to quote '=' in rc args, and i have
to quote ( ) { } * ? and a bunch of other characters.  so what?

> If you're going to allow spaces, then why not allow tabs? ... why not
> newline ... why discriminate against NUL ...

because filenames are supposed to be printable "labels" for things.
tabs are control characters to adjust the "carriage", like CR and NL
are.  NUL is a control character.  space is just a space, and is thought
of as printable.  putting spaces in labels is not a radical idea.  ever
label a paper folder "Mom's recipes"?  i don't feel obligated to put an
underscore in there instead.  and let me tell you, her stuffed peppers
are to die for.

and i've already said it is very useful to have characters that are
guaranteed to be useful as separators.  slashes are used for pathname
element separation, and for the same reason, it seems a good idea to
have a character that always works as an element separator.

so stop confusing the issue.  i'm talking about space.  JUST SPACE.  not
tab, newline, nul, or slash.  i have ALREADY given my reasons for not
allowing those (they are non-printable, and it is good to have reliable
separators).  this is about SPACE ONLY.  the only reason you've given to
hate spaces is shell sloppiness.  we even have the nice new quoted
string functions if you want to use them.

> We could also adopt another Mac OS tradition, case-insensitive file
> names.

this is more questionable.  but in the case of inferno, which has to
live on top of these other systems (windoze does this too), one cannot
simply ignore it.  "mv A a" on inferno used to delete your poor file "A"
instead of move it.  oops.  and i notice that the shell(s) in mac os x
are case-sensitive when using glob matching.

> Pretty soon our file names will be as ungodly a stew as anything ever
> parsed by MVS or VMS.

oh please.  allowing the use of space somehow makes filenames a stew?
give me a break.

[9fans] spaces in filenames

[Michael Baldwin]

really, what is the big deal with spaces in filenames?  yeah, there are
some file formats here and there, and some shell files that maybe aren't
so careful, so it's not a cakewalk, but it isn't some Big Huge Problem.
using shells like rc that manage lists of string works quite well; if
you need a list of files use "ls" not "echo"; if you really want to use
the output of a command with backquote, set ifs to \t\n.

geoff talks about how maddening it is to use filenames with spaces on
mac os x.  i use mac os x too, and have lots of files with spaces, and i
use quotes on the occasion that i refer to them in the shell.  i haven't
noticed any "problem" that would cause me to go mad, and everything
works just fine from the shell and the gui for me.  i send spacey
filenames to web sites, attach/detach them from mail messages, move them
about, and things work.  what am i missing?  now that i can use spaces,
i kinda like using space instead of _ in names -- easier to type and
easier to read.  why banish the poor lowly space character?  so call me
a communist for my radical views.

the only problem i've had with spaces is getting to spacey files on
windows and unix from plan 9 and inferno.  i took out the space
restriction in inferno and things work swimmingly.  yeah, i know there
are gotchas here and there, but they really haven't been an issue.  i
much prefer the ability to manipulate files to the odd gotcha.

oh, the non-printable range also includes 7F, so it's really 00-1F and
7F-9F that are restricted.  it does seem to be a Good Thing that \t and
\n are not allowed, leaving them usable as delimiters.  unix lets you
create such files, but they definitely seem rare, and it is a bit harder
to do from a gui.  who cares if they don't work right.  but leave poor
space alone.

Re: [9fans] spaces in filenames

[Digby Tarvin]

I always rather liked the old Unix approach of the Kernel allowing
anything for which there was no compelling technical reason to forbid.

For file names, that used to be (in the old Bell Labs days) any sequence
of up to 14 bytes, excluding '/' and the NULL used as terminator (both in
the directory entry and the strings passed in system calls).
The subsequent relaxation of the length restriction was certainly a good
thing, but  otherwise I was quite happy with the status quo.

As to to desirability of actually using file names with non-printable
characters - that is certainly questionable. I would prefer
to have a conservative file nameing scheme used in the 'standard'
distribution, refraining from unnecessary use of unprintable
ascii in file names. But I would no more have the operating system enforce
it than I would have the system dictate what bytes appear in a text file.

Most objections to flexible file nameing seem to be the result of syntactic
limitations of the shell which make it difficult to remove or rename
strangely named files when created accidentaly. It was never difficult to
to get rid of them by writing a one line C program.
As I recall, Unix 6th edition came with a 'dsw' (Delete from SWitches) command
to help remove files with funny names. Perhaps something similar is needed.

I do recall once amusing myself as a student arranging to be allocated
inode '0407' for a directory so that with appropriate choice of file
name I could create a directory which would also be an executable
program.

The most compelling reason I can think of for disliking artificial
restrictions on file names (and also case insensitive file names) is
that it is so inconvenient when importing file systems from, or
sharing filesystems with, less restrictive operating systems.

Admittedly you are stuck either way with differences in file name
case sensitivity, but I would rather have the problem of not finding
a file because of a case mis-match than over-writing a file due to
case insensitivity. Although I could probably come up with a scheme
whereby files were stored in a case insensitive way, but directories
could be searched with a 'case insensitive' option which would return
the first match - as a form of wildcarding. It would then be an
application issue weather you were protected from accidentally creating
multiple files differing only in case.

If your file system was case insensitive, a workaround to simulate
case sensitivity would be much more difficult.

One final comment - on the OS-9 operating system (not to be confused
with with MAC OS-9, which it predates by about 20 years...) there is
quite a convenient facility which allows file nameing restrictions to
be varied dynamically. The default disallows, for instance, spaces in
file names. But as a super user, if I want to unpack a tar file which
contains such names, I can temporarily redefine the file name validation
parameters, unpack the archive, and then revert to normal conventions.
This gives the flexibility without the danger of accidental creation
of funny files. Perhaps if this facility were available on a per user
basis, then those that know what they are doing could relax restrictions
when there was a good reason, and others would be protected from mistakes.

Regards,
DigbyT
> really, what is the big deal with spaces in filenames?  yeah, there are
> some file formats here and there, and some shell files that maybe aren't
> so careful, so it's not a cakewalk, but it isn't some Big Huge Problem.
> using shells like rc that manage lists of string works quite well; if
> you need a list of files use "ls" not "echo"; if you really want to use
> the output of a command with backquote, set ifs to \t\n.
>
> geoff talks about how maddening it is to use filenames with spaces on
> mac os x.  i use mac os x too, and have lots of files with spaces, and i
> use quotes on the occasion that i refer to them in the shell.  i haven't
> noticed any "problem" that would cause me to go mad, and everything
> works just fine from the shell and the gui for me.  i send spacey
> filenames to web sites, attach/detach them from mail messages, move them
> about, and things work.  what am i missing?  now that i can use spaces,
> i kinda like using space instead of _ in names -- easier to type and
> easier to read.  why banish the poor lowly space character?  so call me
> a communist for my radical views.
>
> the only problem i've had with spaces is getting to spacey files on
> windows and unix from plan 9 and inferno.  i took out the space
> restriction in inferno and things work swimmingly.  yeah, i know there
> are gotchas here and there, but they really haven't been an issue.  i
> much prefer the ability to manipulate files to the odd gotcha.
>
> oh, the non-printable range also includes 7F, so it's really 00-1F and
> 7F-9F that are restricted.  it does seem to be a Good Thing that \t and
> \n are not allowed, leaving them usable as delimiters.  unix lets you
> create such files, but they definitely seem rare, and it is a bit harder
> to do from a gui.  who cares if they don't work right.  but leave poor
> space alone.
>
--
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk