9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Digby Tarvin <digbyt@acm.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] spaces in filenames
Date: Sat,  1 Jun 2002 17:54:42 +0100	[thread overview]
Message-ID: <200206011654.RAA24007@cthulhu.dircon.co.uk> (raw)
In-Reply-To: <A9A54E16-7510-11D6-8F1F-000393726A14@orb.sh> from Michael Baldwin at "May 31, 2002 11:35:47 pm"

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


  reply	other threads:[~2002-06-01 16:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-01  3:35 Michael Baldwin
2002-06-01 16:54 ` Digby Tarvin [this message]
2002-06-01  5:02 Geoff Collyer
2002-06-01 13:41 ` Michael Baldwin
2002-06-01 13:46 Russ Cox
2002-06-01 13:55 Richard Miller
2002-06-01 14:05 ` William Josephson
2002-06-01 13:15   ` Sam
2002-06-01 14:01 Russ Cox
2002-06-01 14:10 Russ Cox
2002-06-01 14:38 ` William Josephson
2002-06-01 14:15 Russ Cox
2002-06-01 14:16 Russ Cox
2002-06-01 14:55 Richard Miller
2002-06-01 22:16 Russ Cox
2002-06-01 22:17 Russ Cox
2002-06-01 22:25 ` William Josephson
2002-06-03 10:06 ` Axel Belinfante
2002-06-03 12:42 presotto
2011-04-26 18:08 smiley
2011-04-26 18:42 ` Rob Pike
2011-04-26 18:44   ` erik quanstrom
2011-04-26 18:52   ` dexen deVries
2011-04-26 19:31     ` Rob Pike
2011-04-26 19:35       ` Paul Lalonde
2011-04-27 13:10       ` Digby Tarvin
2011-04-27 13:16         ` erik quanstrom
2011-04-27 13:21         ` Steve Simon
2011-04-28  9:58           ` Peter A. Cejchan
2011-04-26 18:43 ` erik quanstrom
2011-04-27  2:30   ` smiley
2011-04-27  2:39     ` erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200206011654.RAA24007@cthulhu.dircon.co.uk \
    --to=digbyt@acm.org \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).