AFAIK, all kinds of brackets, i.e. (),[] and {} are fine on unixish file systems, as are "+", "-", ",", "." and ";" .
Don't use the colon, I think OS-X dislikes it (for compatibility reasons with MacOS-9 and below, where it was the folder separator).
The problem with ? and * is that they can be used as wildcards and were so extensively before the advent of GUIs (when I was young). Thus, you cannot tell "h*s" from "his" or even "hopeless". In other words, when you delete "h*s.txt", a file "hopeless.txt" will be deleted too. And different shells react differently to quotation marks!
···
===
Chevalier Dr. Dr. Ruediger Marcus Flaig
Institute for Immunology
University of Heidelberg
Im Neuenheimer Feld 305, D-69120 Heidelberg, FRG
<flaig@sanctacaris.net>
It used to be, way back when, that 2 (ascii) chars were disallowed in
unix filesystem names; "/" and NUL. Everything else was legal (if
"weird").
···
On 4/20/05, flaig@sanctacaris.net <flaig@sanctacaris.net> wrote:
AFAIK, all kinds of brackets, i.e. (), and {} are fine on unixish file systems, as are "+", "-", ",", "." and ";" .
Don't use the colon, I think OS-X dislikes it (for compatibility reasons with MacOS-9 and below, where it was the folder separator).
The problem with ? and * is that they can be used as wildcards and were so extensively before the advent of GUIs (when I was young). Thus, you cannot tell "h*s" from "his" or even "hopeless". In other words, when you delete "h*s.txt", a file "hopeless.txt" will be deleted too. And different shells react differently to quotation marks!
===
Chevalier Dr. Dr. Ruediger Marcus Flaig
Institute for Immunology
University of Heidelberg
Im Neuenheimer Feld 305, D-69120 Heidelberg, FRG
<flaig@sanctacaris.net>
You're right Austin. Perhaps a good idea would be to pressure file
system developers to give files two fields: one a File Key and another
a File Title, so we can have both usages. Or will that in itself cause
worse problems?
> It used to be, way back when, that 2 (ascii) chars were disallowed in
> unix filesystem names; "/" and NUL. Everything else was legal (if
> "weird").
Legal doesn't mean it's a good idea.
Of course not. That's not what I was asserting; I was simply replying
to another poster who wrote:
AFAIK, all kinds of brackets, i.e. (), and {} are fine on unixish file systems, as are "+", "-", ",", "." and ";" .
Which in fact is correct.
Not that it matters, but I'm (also) against naming files using a
meta-char (i.e. "?") in arguably the most ubiquitous shells in use
today.
···
On 4/21/05, Austin Ziegler <halostatue@gmail.com> wrote:
On 4/20/05, Michael Campbell <michael.campbell@gmail.com> wrote:
It won't cause worse problems, but it won't help with the bane of
all computer scientists.
Legacy systems.
A DBFS can help with this, certainly, but it won't solve it.
I meant to send a reply to this thread long before that said
essentially what I said above, PLUS:
* I can't find the message reference right now, but I seem to recall
that Matz indicated that "require 'foo/bar'" requires the
*resource* "foo/bar", similar to the way that in Perl "using
Foo::Bar;" uses that resource. Thus, it might be worth an RCR to
do some limited translation on certain characters so that they are
safe for all operating systems. Then, you could do require
'facets/nil?' and it would load the resource "facets/nil%3f".
This would place a burden on the developer to make sure that the
file is saved as nil%3f.rb, but it would work.
-austin
···
On 4/21/05, Trans <transfire@gmail.com> wrote:
Legal doesn't mean it's a good idea.
You're right Austin. Perhaps a good idea would be to pressure file
system developers to give files two fields: one a File Key and
another a File Title, so we can have both usages. Or will that in
itself cause worse problems?
Not that it matters, but I'm (also) against naming files using a
meta-char (i.e. "?") in arguably the most ubiquitous shells in use
today.
I find this curious becuase we dela with this kind of thing all the
time in regexp --the need to escape certain characters b/c of their
special meaning. So in the case of file names couldn't ? and * be
escaped just as easily? I do think it is ultimately preferable that
file names be free-form. Take for instance what my Grandmother did
today. She was image searching her name on Google. She came across a
picture with a path name ending in 'm_callas.jpg'. She actually infered
the name Mary Callas from that. I would have never knowned myself --too
bad it doesn't just say 'Mary Callas'. Of course it could, but that
comes out as Mary%20Callas, or something. I'm smart enough to infer
obviously, but isn;t it rather silly that we Humans have to put up with
the techno garble?
This would place a burden on the developer to make sure that the
file is saved as nil%3f.rb, but it would work.
Actually, couldn't gem do this automagically, laying out filenames compatible with the destination filesystem? The developer can store whatever file name he wishes into the gem without regard to worries about the destination filesystem.
It won't cause worse problems, but it won't help with the bane of
all computer scientists.
Legacy systems.
All too True.
A DBFS can help with this, certainly, but it won't solve it.
One day....
I meant to send a reply to this thread long before that said
essentially what I said above, PLUS:
* I can't find the message reference right now, but I seem to recall
that Matz indicated that "require 'foo/bar'" requires the
*resource* "foo/bar", similar to the way that in Perl "using
Foo::Bar;" uses that resource. Thus, it might be worth an RCR to
do some limited translation on certain characters so that they are
safe for all operating systems. Then, you could do require
'facets/nil?' and it would load the resource "facets/nil%3f".
This would place a burden on the developer to make sure that the
file is saved as nil%3f.rb, but it would work.
That's interesting...very interesting. I wonder what Matz would think.
They *can* be escaped, but why force that need on your users when
there's no good reason to?
···
On 4/22/05, Trans <transfire@gmail.com> wrote:
> Not that it matters, but I'm (also) against naming files using a
> meta-char (i.e. "?") in arguably the most ubiquitous shells in use
> today.
I find this curious becuase we dela with this kind of thing all the
time in regexp --the need to escape certain characters b/c of their
special meaning. So in the case of file names couldn't ? and * be
escaped just as easily?
Um. I'm thinking outside of gems. I'm thinking in terms of Ruby. Not
everything is done with Gems, even if they are extremely convenient
right now.
-austin
···
On 4/21/05, B. K. Oxley (binkley) <binkley@alumni.rice.edu> wrote:
Austin Ziegler wrote:
This would place a burden on the developer to make sure that the
file is saved as nil%3f.rb, but it would work.
Actually, couldn't gem do this automagically, laying out filenames
compatible with the destination filesystem? The developer can
store whatever file name he wishes into the gem without regard to
worries about the destination filesystem.
They *can* be escaped, but why force that need on your users when
there's no good reason to?
But this is a need for advance users, i.e. us progammers and system
administrators. And so to save us from the occasional escaping,
_end-users_ have to deal with things like underscores and %20s and what
not.
Um. I'm thinking outside of gems. I'm thinking in terms of Ruby. Not
everything is done with Gems, even if they are extremely convenient
right now.
Of course. For the mechanism to work, Ruby would need to know to do the translations for require. I was thinking that as a help for the programmer-at-arms, the gem system would provide a translation automatically. For distribution of code outside of gems, the programmer would need to perform the translation of filenames manually or with a utility tool.