From: Michael Baldwin <m@orb.sh>
To: 9fans@cse.psu.edu
Subject: [9fans] spaces in filenames
Date: Fri, 31 May 2002 23:35:47 -0400 [thread overview]
Message-ID: <A9A54E16-7510-11D6-8F1F-000393726A14@orb.sh> (raw)
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.
next reply other threads:[~2002-06-01 3:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-01 3:35 Michael Baldwin [this message]
2002-06-01 16:54 ` Digby Tarvin
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=A9A54E16-7510-11D6-8F1F-000393726A14@orb.sh \
--to=m@orb.sh \
--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).