At 06:49 AM 3/13/2002 -0600, Bryn Wolfe wrote:

>I think we're getting a little too much of the old school of thought here.

Hmm... the "old school of thought" was that documentation and references 
should be clear and unambiguous. No, we don't have enough of the old 
school, not too much.

>  Not allowing lowercase is just too primative. If you're going to take 
> away the spaces, give me my lowercase.

That's even worse than spaces. Some file systems (such as DOS, up through 
NTFS, if I am correct) treat lower case and upper case as equivalent. Some 
don't (i.e., unix et al).

A system that should be compatible with both -- and I think that desireable 
-- will necessarily avoid lower case, or will treat lower case the same as 
upper case. The former is better than the latter, in my opinion.

Removing the length restriction was sufficient to provide for enough fully 
descriptive names that the additional space of lower case is completely 
unnecessary. Note that it is difficult to read lower and upper case as 
being distinct from one another. If I communicate the name of a part 
verbally it is convoluted for me to include case information. It is not a 
natural representation of the language. Some languages don't have this 
distinction, Arabic for one. Latin for another, I think.

>  To avoid the filename-in-quotations-because-of-spaces problem I rarely 
> use spaces and instead use lowercase with the first letter of each word 
> capitalized. I'm and advocate of being succinct, but clear. Losing 
> lowercase is a detriment in my opinion. I want to allow every character 
> that is possible for a file name, excluding spaces. In windows, this 
> excludes the following characters.
>\ / : * ? " < > |

I agree.

Quotation marks should not be used; if they are allowed, many user-written 
utilities will need to become more complex and bug-prone.

>I believe that is the same restriction for Unix-related OSes and Solaris. 
>It works for them, why not for us? And this lower case oh (o) vs zero (0) 
>and lowercase ell (l) vs one (1) is simply a font problem. You might as 
>well not allow the upper case letter oh (O) either because it looks like a 
>zero (0) as well. Just fix the font, no big deal.

That is, in fact, the only solution to this one, because we need the letter 
O and we also need the number 0. I favor the slash for zero, in spite of 
what was on the reference cited by another. But any font device that makes 
the distinction unambiguous is fine with me. As to the problems with the 
Nordic languages, well, I don't think we can solve everything.

You should see what is involved in trying to write Arabic in ASCII. It is a 
total mess....

>I believe we can think outside the teletype restrictions of 30 years ago. 
>If not, maybe it's time to retire ;-)

Ahem. The issue is clarity, and what could easily be taken as a personal 
insult will not help to resolve it.

Allowing lower case letters can improve clarity, mostly by being a signal 
for word gaps. But underscore fills that need nicely, without the added 
complications introduced by lower case.

As long as the Windows file system treats upper and lower case as the same, 
I would be very much against preserving lower-upper case distinctions in 
file names. Allowing them to be entered and kept can cause confusion, i.e., 
one does not automatically know if case is important or if it is not. The 
program should handle that for the user, i.e., if the user enters lower 
case, it should be represented as upper case immediately. If a user enters 
a space, it should immediately become an underscore.

Abdulrahman Lomax
Easthampton, Massachusetts USA

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to