On NT a ? is not really an acceptable filename character.
* probably also gives one a hard time.
While these are legal on the various UNIX boxes
(so long as you escape them from the shell or write direct
OS calls in some other language). Other chars are not:
"/" inside a name isn't. The OS wants to use a sub-directory.
"." and ".." are special too.
I don't want subdirs though. Bad security flaw if
general public can traverse subdirs when you don't want them to.
Not a good enough reason to limit the namespace either.
Namespace limitation should be in the hands of the
app-architect not at the mercy of geeky OS writers.
I cant see myself saying:
"I'm sorry, you cant pick a name the same as your
signature (or emoticons like ;/ B{] (c: ) because the
database/OS has a [insert euphemism here] limitation
and 150 experts tried to get around it and gave up."
So I need a mapper function. Maybe two (or three).
One to convert an arbitrary string of characters
to a legal (and recognizable if only alpahnumerics and _ are used)
filename. The second function is to go back the other way -
derive the original string from the encoding.
url-encoded is close. Consider that I want to store
stuff under the name of any legitimate rebol word
or operator including all the punctuation and NUL.
You got 256 chars - I want to use them all.
(or rather my user-base wants no such non-portable limits )
[ extra credit: UTF7 or UTF8 capable would get
my need for kanji/unicode out of the way later]
The third function would look in a real directory of my choice
and return me the list of decoded filenames
so I could tell which 'words already were spoken for
or have something stored. - a refinement for list-dir.
[[extra GUI points if you handle a filename with a blank tab
or other whitespace in a way instantly comprehendible
by a non-techie, even more points if the result is a
clickable HTML table or can be so converted ]]
No fair making a mapping-block or index of filenames
and storing that externally. Other running apps (which
I do not have source code to) may be adding to the files
and there are preexisting files (with normal names)
already present.
Your work would become visible right away
since we have a test case for your 3 functions
waiting. The wiki.r I have been rewriting
is giving the NT box a hernia over things like 'value?
and the unix box is not too happy with // and /
for some reason. <wink>
;# mailto: [EMAIL PROTECTED]
