From: Jim Choate <ravage@ssz.com>
To: 9fans@cse.psu.edu
Cc: hangar18-general@open-forge.org
Subject: [9fans] Re: blanks in file names
Date: Wed, 10 Jul 2002 17:42:30 -0500 [thread overview]
Message-ID: <Pine.LNX.3.96.1020710172424.27892N-100000@einstein.ssz.com> (raw)
In-Reply-To: <200207102158.g6ALw3s08063@dave2.dave.tj>
On Wed, 10 Jul 2002, Dave wrote:
> If I had to vote a priori, blanks would certainly be a no-go for
> filenames. However, the pressure cooker has already burst, and our
> chicken is headed straight towards the ceiling. Getting rid of spaces in
> filenames is not much of an option, if we want to be able to get along
> in the wide world of non-space-restricted systems.
Um, strictly speaking for most OS'es (and logically in general) the
'string' that represents the filename canonicaly -should- be (usually) ""
delimited.
In other words,
ls filename.foo
should really be,
ls "filename.foo"
or perhaps,
ls "file/"Bill/".foo"
The fact that the OS allows one to drop them (assuming you don't use
things like blanks in filenames) is really a courtesy of the shell
implimentation. That's where it should stay. Why the filesystem would
-ever- need the filename for internal operations would, at least to my
mind, be a major error in implimentation. Other than in 'friendly name'
situations (ie UI related) the system should be oblivious of the filename.
If it's a valid character in the character set, it should be allowed in a
string (except for logical issues - eg printing some non-printable) should
print some sort of symbol allowing one to recognize this. This
'conversion' should also stay strictly in the UI related code. To do
otherwise raises a host of issues about side effects and special cases w/
regard to sting handling libraries. To not allow spaces in filenames only
makes the world more complicated. It also destroys a layer of generality,
and that is -almost always- a BAD thing.
With respect to filenames, it's a string of -reasonably- unique (re issues
of location and such) 1's and 0's to the OS. It doesn't really 'mean'
anything to the OS::File System. It's the User::UI that it matters to.
User::UI::OS::File System
Leave the problem where it belongs, in the cli/shell.
--
____________________________________________________________________
When I die, I would like to be born again as me.
Hugh Hefner
ravage@ssz.com www.ssz.com
jchoate@open-forge.org www.open-forge.org
--------------------------------------------------------------------
next prev parent reply other threads:[~2002-07-10 22:42 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-03 8:00 [9fans] " Fco.J.Ballesteros
2002-07-03 12:00 ` Lucio De Re
2002-07-03 19:39 ` rob pike, esq.
2002-07-07 4:02 ` Dave
2002-07-07 5:17 ` arisawa
[not found] ` <"arisawa@ar.aichi-u.ac.jp"@Jul>
2002-07-07 5:38 ` Dave
2002-07-07 6:04 ` arisawa
2002-07-07 7:16 ` arisawa
2002-07-07 16:11 ` Dave
2002-07-07 16:12 ` Dave
2002-07-09 15:31 ` [9fans] acme question + diffs for kfs, fs and plumbing Dave
2002-07-09 22:15 ` arisawa
2002-07-10 21:58 ` [9fans] blanks in file names Dave
2002-07-10 22:38 ` arisawa
2002-07-10 22:42 ` Jim Choate [this message]
2002-07-11 5:08 ` [9fans] " Dave
2002-07-11 5:10 ` [9fans] " Dave
2002-07-14 18:32 ` Dave
2002-07-14 18:51 ` Jim Choate
2002-07-14 23:27 ` arisawa
2002-07-08 9:48 ` Boyd Roberts
2002-07-08 20:22 ` Dave
2002-07-09 8:24 ` Boyd Roberts
2002-07-09 15:25 ` Dave
2002-07-08 23:05 ` Berry Kercheval
2002-07-09 7:50 [9fans] acme question + diffs for kfs, fs and plumbing Fco.J.Ballesteros
2002-07-09 8:15 ` Lucio De Re
2002-07-09 8:42 ` arisawa
2002-07-09 9:21 ` Lucio De Re
2002-07-09 9:43 ` arisawa
2002-07-09 10:36 ` Lucio De Re
2002-07-09 10:54 ` matt
2002-07-09 11:01 ` Liberating the filename (Was: [9fans] acme question + diffs for kfs, fs and plumbing) Lucio De Re
2002-07-09 11:07 ` arisawa
2002-07-11 14:57 ` Liberating the filename (Was: [9fans] acme question + diffs forkfs, Douglas A. Gwyn
2002-07-09 8:22 ` [9fans] acme question + diffs for kfs, fs and plumbing arisawa
2002-07-09 7:54 [9fans] blanks in file names Fco.J.Ballesteros
[not found] ` <Fco.J.Ballesteros@Jul>
2002-07-09 15:23 ` Dave
2002-07-09 15:29 ` [9fans] acme question + diffs for kfs, fs and plumbing Dave
2002-07-10 15:57 ` Dave
2002-07-10 16:02 ` [9fans] blanks in file names Dave
2002-07-10 20:59 ` FJ Ballesteros
2002-07-10 21:51 ` Dave
2002-07-10 22:22 ` Dan Cross
2002-07-10 23:01 ` Dave
2002-07-11 2:00 ` Dan Cross
2002-07-11 6:14 ` Dave
2002-07-11 6:38 ` Lucio De Re
2002-07-14 18:00 ` Dave
2002-07-11 13:14 ` arisawa
2002-07-12 12:28 ` arisawa
2002-07-11 16:23 ` Dan Cross
2002-07-11 10:43 ` Ish Rattan
2002-07-14 18:49 ` Dave
2002-07-09 8:42 [9fans] acme question + diffs for kfs, fs and plumbing Fco.J.Ballesteros
2002-07-09 9:28 ` Lucio De Re
2002-07-09 11:23 ` andrey mirtchovski
2002-07-09 12:05 ` matt
2002-07-10 7:57 Fco.J.Ballesteros
2002-07-10 8:00 [9fans] blanks in file names Fco.J.Ballesteros
2002-07-10 18:27 David Gordon Hogan
2002-07-10 20:56 ` arisawa
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=Pine.LNX.3.96.1020710172424.27892N-100000@einstein.ssz.com \
--to=ravage@ssz.com \
--cc=9fans@cse.psu.edu \
--cc=hangar18-general@open-forge.org \
/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).