CAPS Fantasia (was: argv for z/OS C++ batch)
Paul Gilmartin
>
>- Yes, I'm clear on the difference between the restrictions imposed by PARM=
>(one parm, 100 chars), TSO (a tendency to convert to U/C, and yes, I agree
>with gil, over-compensating by converting to l/c when ASIS is specified is
>just brain dead), ISPF (a tendency to convert to u/c), and C argv (only one
>parm, possibly parsed into words).
>
Wouldn't it have been glorious if the original definition of 6-bit
BCD had specified lower case alphabetics _instead_of_ upper case?
FORTRAN (excuse me) fortran programs would have been written in
lower case; data set names would be lower case; and jcl would be
lower case (but programmers might need to surround 'Upper Case'
characters with apostrophes lest they be flagged as invalid). There
would be no tendency for tso to convert to upper case, and there
would be no need for an ASIS option. Nor would there be any
particular use for the ispf editor's having a CAPS ON/OFF setting.
Ah, well.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Charles Mills
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Tuesday, December 29, 2009 12:28 PM
To: IBM-...@bama.ua.edu
Subject: CAPS Fantasia (was: argv for z/OS C++ batch)
On Sun, 27 Dec 2009 10:01:32 -0500, Charles Mills wrote:
>
>- Yes, I'm clear on the difference between the restrictions imposed by
PARM=
>(one parm, 100 chars), TSO (a tendency to convert to U/C, and yes, I agree
>with gil, over-compensating by converting to l/c when ASIS is specified is
>just brain dead), ISPF (a tendency to convert to u/c), and C argv (only one
>parm, possibly parsed into words).
>
Wouldn't it have been glorious if the original definition of 6-bit
BCD had specified lower case alphabetics _instead_of_ upper case?
FORTRAN (excuse me) fortran programs would have been written in
lower case; data set names would be lower case; and jcl would be
lower case (but programmers might need to surround 'Upper Case'
characters with apostrophes lest they be flagged as invalid
----------------------------------------------------------------------
Paul Gilmartin
>Would UNIX then have used all upper case just to be different?
>
It's plausible. It might have been swayed in that direction by the
Teletype KSR33, which generates only upper case codes while 7-bit
ASCII defines both upper and lower case.
In "man stty" I see:
iuclc Map uppercase alphabetic characters to lowercase on input.
olcuc Map lowercase alphabetic characters to uppercase on output.
xcase Set canonical uppercase or lowercase presentation.
lcase Set xcase, iuclc, and olcuc.
-lcase Disable xcase, iuclc, and olcuc.
LCASE Equivalent to lcase.
-LCASE Equivalent to -lcase.
... obvious concessions to upper case only terminal devices such
as the KSR33.
-- gil
Shmuel Metz , Seymour J.
at 11:28 AM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Wouldn't it have been glorious if the original definition of 6-bit BCD
>had specified lower case alphabetics _instead_of_ upper case?
Plus �a change, plus c'est la m�me chose.
>FORTRAN (excuse me) fortran programs would have been written in lower
>case; data set names would be lower case; and jcl would be lower case
>(but programmers might need to surround 'Upper Case' characters with
>apostrophes lest they be flagged as invalid). There would be no
>tendency for tso to convert to upper case,
Instead, TSO would convert to lower case. I don't see how that would be
any better. The proper design would have been to be case independent from
the get-go; S/360 started with a new, 8 bit, character set.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Paul Gilmartin
>In <LISTSERV%20091229112...@BAMA.UA.EDU>, on 12/29/2009
> at 11:28 AM, Paul Gilmartin said:
>
>>Wouldn't it have been glorious if the original definition of 6-bit BCD
>>had specified lower case alphabetics _instead_of_ upper case?
>
>Plus a change, plus c'est la mme chose.
>
>>FORTRAN (excuse me) fortran programs would have been written in lower
>>case; data set names would be lower case; and jcl would be lower case
>>(but programmers might need to surround 'Upper Case' characters with
>>apostrophes lest they be flagged as invalid). There would be no
>>tendency for tso to convert to upper case,
>
>Instead, TSO would convert to lower case. I don't see how that would be
>any better. The proper design would have been to be case independent from
>the get-go; S/360 started with a new, 8 bit, character set.
>
What objective would be served by converting to lower case?
Typewriter keyboards by default generate lower case. Support
for Teletype KSR 33, perhaps?
-- gil
Tom Marchant
>On Wed, 30 Dec 2009 16:48:38 -0500, Shmuel Metz (Seymour J.) wrote:
>>
>>Instead, TSO would convert to lower case. I don't see how that would be
>>any better. The proper design would have been to be case independent from
>>the get-go; S/360 started with a new, 8 bit, character set.
>>
>What objective would be served by converting to lower case?
Easier parsing. If everything input is all in one case, it is a bit easier
to parse the commands and options entered.
>Typewriter keyboards by default generate lower case. Support
>for Teletype KSR 33, perhaps?
There were many older teletypes before the KSR 33. Fifty years worth of
them, if memory serves. All upper case only.
--
Tom Marchant
Paul Gilmartin
>On Wed, 30 Dec 2009 22:13:58 -0600, Paul Gilmartin wrote:
>
>>What objective would be served by converting to lower case?
>
>Easier parsing. If everything input is all in one case, it is a bit easier
>to parse the commands and options entered.
>
This shortly becomes totalitarion; Procrustean. For example,
there's no way to pass mixed case data under control of
"allocate dsn(*) ...". There ought at least to be an ASIS/CAPS
option on that construct, not the apparent attitude of "We don't
need no steenkin lower case."
>>Typewriter keyboards by default generate lower case. Support
>>for Teletype KSR 33, perhaps?
>
>There were many older teletypes before the KSR 33. Fifty years worth of
>them, if memory serves. All upper case only.
>
I called it a fantasia. UNIX has done well without pervasive case munging.
-- gil
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Paul Gilmartin
To: IBM-...@bama.ua.edu
Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
<SNIPPAGE>
I called it a fantasia. UNIX has done well without pervasive case
munging.
<SNIPPAGE>
So has M/S Winders.
However, systems that are built based on prior functioning code and
ideas of how things should be done, now get the shaft because we now
take it that ONE IS SHOUTING BY USING ALL UPPER CASE AS IT USED TO BE.
IN FACT, MIXED CASE IS A NEW CONSTRUCT. HOW MANY WRITTEN LANGUAGES HAD
MIXED CASE PRIOR TO 1400 AD/CE?
Get over it. Or go buy your own cheese to go with the w[h]ine.
Regards,
Steve Thompson
-- Opinions expressed by this poster in this posting are entirely those
of this poster. --
P S
> UNIX has done well without pervasive case munging.
>
You misspelled "despite" as "without" :-(
I often wonder how many millions of man-hours and real dollars have been
lost due to case-sensitivity in *IX. I've repeatedly asked *IX types about
it, and they insist it's good, while (a) not being able to explain why and
(b) agreeing that they would never deliberately create two files with the
same name but different case.
IMHO, Windows actually got this one right...
McKown, John
I remember in the past when the 3270 (3278?) had the ability to display lower case, but had a switch to automunge lower case to upper. One person in particular would switch this on. Then enter a ticket about a JCL error due to an MVS problem. I flip the switch and show him that the JCL was in lower case. He then would curse at the system. Fix the error. Flip the switch back to "upper convert". Then repeat the same problem again (and again and ...) and enter another MVS failure ticket.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Thursday, December 31, 2009 10:50 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
>
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of McKown, John
Sent: Thursday, December 31, 2009 11:00 AM
To: IBM-...@bama.ua.edu
Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
I think that the case munging of some things was due to the 3277. I
vaguely remember that it would, originally?, only display upper case,
but that the keyboard would enter things in lower case. And the caps
lock sucked in that it wasn't a caps lock, but a shift lock which
affected the numbers vs. special characters on the top row. So, TSO just
decided to upper case most everything to help out.
I remember in the past when the 3270 (3278?) had the ability to display
lower case, but had a switch to automunge lower case to upper. One
person in particular would switch this on. Then enter a ticket about a
JCL error due to an MVS problem. I flip the switch and show him that the
JCL was in lower case. He then would curse at the system. Fix the error.
Flip the switch back to "upper convert". Then repeat the same problem
again (and again and ...) and enter another MVS failure ticket.
<SNIP>
I remember a certain IPCS standalone dump where the 3278/9 displays were
typically set to upper only, and no one caught the fact that "ASCB" in
the first ASCB in the system was actually "aSCB". It caused the system
to go to a hard wait.
And I remember an application where I was doing development -- no one
told me that terminals were now doing mixed case from the keyboard, with
things being lower case. So I had to learn to OC the input...
I STILL READ UPPER CASE NORMALLY -- iT DoEsN't sEeM lIke sHoUtInG tO Me.
But then, I still have 5081s. However, my TN3270 emulation is set for
mixed.
Later,
Steve Thompson
-- Opinions expressed by this poster may not reflect those of poster's
employer. --
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of P S
> Sent: Thursday, December 31, 2009 10:56 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
>
> <PaulGB...@aim.com>wrote:
>
> > UNIX has done well without pervasive case munging.
> >
>
> You misspelled "despite" as "without" :-(
>
> I often wonder how many millions of man-hours and real
> dollars have been
> lost due to case-sensitivity in *IX. I've repeatedly asked
> *IX types about
> it, and they insist it's good, while (a) not being able to
> explain why and
> (b) agreeing that they would never deliberately create two
> files with the
> same name but different case.
>
> IMHO, Windows actually got this one right...
Hum, I have exactly the opposite opinion. I dislike Windows' "case preserving" but "case ignoring" feature. I think that Mac OSX is like Windows in this as well (and it is UNIX based). If it is going to ignore case, then it should automagically change all file names to either all upper or all lower case in the filesystem. And, if really desired, somebody could write a UNIX filesystem which does this same "case ignoring" (by up casing or lower casing the input) when doing a file lookup and "automatic upper/lower casing" when storing the file in the filesystem. Of course, people do like to "CamelCase" file names to make them more readable. And I agree that I can't see why anybody would want the files: foo , Foo , fOo , FOo, and so on in a directory.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Howard Brazee
wrote:
>>What objective would be served by converting to lower case?
>
>Easier parsing. If everything input is all in one case, it is a bit easier
>to parse the commands and options entered.
Significantly easier?
Paul Gilmartin
>
>However, systems that are built based on prior functioning code and
>ideas of how things should be done, now get the shaft because we now
>take it that ONE IS SHOUTING BY USING ALL UPPER CASE AS IT USED TO BE.
>
>IN FACT, MIXED CASE IS A NEW CONSTRUCT. HOW MANY WRITTEN LANGUAGES HAD
>MIXED CASE PRIOR TO 1400 AD/CE?
>
>Get over it. Or go buy your own cheese to go with the w[h]ine.
>
You seem to be the one whining about 600 years of tradition.
Do you really want to go back to the conventions of 1400?
Why didn't you submit your entire message in upper case?
The answer comes down to social pressure. And that pressure
requires that modern anglophones be addressed in mixed case.
I might grant that programming languages can be very successful
in a single case. But nowadays the clientele demands the
prevalent typographical conventions, for data at least. But
it's often difficult to isolate data from code.
It's generally welcomed that HLASM treats as equivalent:
DC C'Steve Thompson'
and
dc c'Steve Thompson'
but different from:
DC C'STEVE THOMPSON'
But I consider it a disservice that "dsn(*)" forces upper
case. That's text data, not code.
-- gil
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Howard Brazee
> Sent: Thursday, December 31, 2009 11:14 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
>
Unfortunately, in UNIX, a lot of command have options where the lower case letter means one thing and the corresponding upper means another. One example that I used recently was nftsclone. With that -O means "output to specified file whether it exist or not" and -o means "output to file only if it does not exist, otherwise fail". The "long form" is better, IMO.
--output file.only.if.doesnt.exist
and
--overwrite file.whether.if.exists.or.not
I've seen other UNIX commands where the lower case option means one thing and the corresponding upper is totally unrelated. Poor application design, IMO. Many UNIX programmers are still in the "make the command like as short as possible in order to save keystrokes" mode. This was good back in the 110 baud teletype era. It sucks today.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
P S
John....@healthmarkets.com> wrote:
> Hum, I have exactly the opposite opinion. I dislike Windows' "case
> preserving" but "case ignoring" feature. I think that Mac OSX is like
> Windows in this as well (and it is UNIX based). If it is going to ignore
> case, then it should automagically change all file names to either all upper
> or all lower case in the filesystem. And, if really desired, somebody could
> write a UNIX filesystem which does this same "case ignoring" (by up casing
> or lower casing the input) when doing a file lookup and "automatic
> upper/lower casing" when storing the file in the filesystem. Of course,
> people do like to "CamelCase" file names to make them more readable. And I
> agree that I can't see why anybody would want the files: foo , Foo , fOo ,
> FOo, and so on in a directory.
>
OK, *not* trying to start a war, honestly curious: why do you dislike it?
(The 8.3 filenames are, of course, all uppercase, btw.) Why should it upper-
or lowercase the filenames? What would that buy?
Mind you, an *option* to say "DISPLAY FILENAMES IN ALL upper/lower CASE"
would be a plausible option. CamelCase is useful for readability -- studies
have proven that (he says, without citation but with confidence).
Tom Marchant
>On 31 Dec 2009 07:40:03 -0800, Tom Marchant wrote:
>
>>>What objective would be served by converting to lower case?
>>
>>Easier parsing. If everything input is all in one case, it is a bit easier
>>to parse the commands and options entered.
>
>Significantly easier?
Maybe not. I think Shmuel was right to assume that if BCD was lower case
only that TSO would have converted everything to lower case just as in fact
it converts everything to upper case. Why would it do that? My guess is to
make it easier. I did say "a bit easier". If I was coding a parser today,
I'd probably copy the input line to another area, translate the copy to all
upper (or lower) case and parse, then extract data from the untranslated copy.
--
Tom Marchant
Tom Marchant
>On Thu, 31 Dec 2009 09:39:13 -0600, Tom Marchant wrote:
>
>>On Wed, 30 Dec 2009 22:13:58 -0600, Paul Gilmartin wrote:
>>
>>>What objective would be served by converting to lower case?
>>
>>Easier parsing. If everything input is all in one case, it is a bit easier
>>to parse the commands and options entered.
>>
>This shortly becomes totalitarion; Procrustean. For example,
>there's no way to pass mixed case data under control of
>"allocate dsn(*) ...". There ought at least to be an ASIS/CAPS
>option on that construct, not the apparent attitude of "We don't
>need no steenkin lower case."
I agree.
Barry Merrill
I remember opening the case and mounting a switch on the
bottom (from Radio Shack, of course) and soldering it so
that the editor recognized lower case, so my 1980 book,
written on that machine, had mixed case.
Of course, the OS didn't support the switch, and produced
garbage from key strokes if the switch was in the mixed
case position.
MXG was ALWAYS upper case only, until the nix's came into
being, forcing some members to be case-dependent, which I
abhor, but now must live with. FOO, foo fOO and Foo to
whomever made that unwise choice.
Happily New Year,
Barry Merrill
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of P S
> Sent: Thursday, December 31, 2009 11:35 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
>
>
> dislike it?
> (The 8.3 filenames are, of course, all uppercase, btw.) Why
> should it upper-
> or lowercase the filenames? What would that buy?
>
> Mind you, an *option* to say "DISPLAY FILENAMES IN ALL
> upper/lower CASE"
> would be a plausible option. CamelCase is useful for
> readability -- studies
> have proven that (he says, without citation but with confidence).
I honestly don't have a good reason. I guess I think that "if you're going to ignore the case of a file name, then why bother to maintain it?". And I'm not rabid about it, at all. Likely just my own type of insanity <grin>.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Thursday, December 31, 2009 11:22 AM
To: IBM-...@bama.ua.edu
Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
On Thu, 31 Dec 2009 11:55:33 -0500, Thompson, Steve wrote:
>
>However, systems that are built based on prior functioning code and
>ideas of how things should be done, now get the shaft because we now
>take it that ONE IS SHOUTING BY USING ALL UPPER CASE AS IT USED TO BE.
>
>IN FACT, MIXED CASE IS A NEW CONSTRUCT. HOW MANY WRITTEN LANGUAGES HAD
>MIXED CASE PRIOR TO 1400 AD/CE?
>
Greek?
>Get over it. Or go buy your own cheese to go with the w[h]ine.
>
You seem to be the one whining about 600 years of tradition.
Do you really want to go back to the conventions of 1400?
Why didn't you submit your entire message in upper case?
The answer comes down to social pressure. And that pressure
requires that modern anglophones be addressed in mixed case.
<SNIPPAGE>
Well, since I've actually written a few compilers, deal with syntax
parsing in my current job, have dealt with it in prior jobs, I just
thought I'd throw in a bit of history. You just have to accept that
different systems were designed and implemented by people who have
different reasons for doing things that don't match what you (whoever
"you" might be) might like -- making intercommunications between
architectures fraught with land mines.
Meanwhile, I had thought that Greek had a single case until about
1300AD/CE. And that until Gutenburg and the press, most European written
languages were uni-case (upper and lower were available, but once you
started writing in one you stayed there -- English has one set of rules,
German has another, and English came from German, with some French
thrown in for good measure).
Regards,
Steve Thompson
-- Opinions expressed by this poster may not reflect those of poster's
employer --
Paul Gilmartin
>On Thu, Dec 31, 2009 at 12:08 PM, McKown, John wrote:
>
>> Hum, I have exactly the opposite opinion. I dislike Windows' "case
>> preserving" but "case ignoring" feature. I think that Mac OSX is like
>> Windows in this as well (and it is UNIX based). If it is going to ignore
>>
Since perhaps 10.2; certainly 10.3, OS X provides the option of
formatting a filesystem as case-sensitive or case-insensitive.
It is rumored that many vendor apps fail on a case-sensitive FS.
I've encountered only one, and it was fixed in a later release.
>> case, then it should automagically change all file names to either all upper
>> or all lower case in the filesystem. And, if really desired, somebody could
>> write a UNIX filesystem which does this same "case ignoring" (by up casing
>> or lower casing the input) when doing a file lookup and "automatic
>> upper/lower casing" when storing the file in the filesystem. Of course,
>> people do like to "CamelCase" file names to make them more readable. And I
>> agree that I can't see why anybody would want the files: foo , Foo , fOo ,
>> FOo, and so on in a directory.
>>
Identifiers, at least. In typography, the HTML (SGML?) entities
Á and á have different meanings. It was one obvious
way of distinguishing them; opinions will vary as to which is best.
Then if the bitmaps or outline instructions are stored in a
filesystem, Aacute.bmp and aacute.bmp are obvious choices.
>OK, *not* trying to start a war, honestly curious: why do you dislike it?
>(The 8.3 filenames are, of course, all uppercase, btw.) Why should it upper-
>or lowercase the filenames? What would that buy?
>
Ease in sorting and searching. If I were implementing such a filesystem,
I'd store the names in a single case followed by a bitmap indicating
which case to display.
>Mind you, an *option* to say "DISPLAY FILENAMES IN ALL upper/lower CASE"
>would be a plausible option. CamelCase is useful for readability -- studies
>have proven that (he says, without citation but with confidence).
>
Long ago, I experimented with STOW from assembler. It uncomplainingly
creates member names in mixed case, and worse. At that time, I could
operate on such members by selecting them from a member menu, but not
by typing the names on the command line, whether quoted or not.
My strong bias is that such rules should be enforced by the filesystem,
not haphazardly by the APIs in various languages: typing 'FooBar'
in Assembler, JCL, TSO, C, etc. should all produce the uniform results
because the string should be passed ASIS to STOW, BLDL, DESERV,
etc. which should make the decision on how to handle mixed case:
o full case-sensitivity or
o Lower case is invalid or
o case insignificant to the FS, but preserved for display.
At the lowest level, the z/OS filesystem is fully case-sensitive.
Assembler, at least, respects this (How could it be otherwise?
Well, the BLDL and STOW macros could convert the case before
issuing the SVC.) Other APIs should respect the programmers'
conventions even as assembler does.
And I've experimented with Samba and filenames differing in only case
of the characters. It seems sensitive to version of client. I recall
both seeing one of the names converted to 8.3, but later seeing both
names displayed as in the UNIX directory, but when I click on one it's
unpredictable which one will open.
-- gil
Gord Tomlin
> Long ago, I experimented with STOW from assembler. It uncomplainingly
> creates member names in mixed case, and worse. At that time, I could
> operate on such members by selecting them from a member menu, but not
> by typing the names on the command line, whether quoted or not.
Not everything was so benign. Think back to SMP4 and 3270s...there were
member names in some of the data sets that would cause I/O errors when
attempting to display the member list in ISPF browse.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
P S
> >OK, *not* trying to start a war, honestly curious: why do you dislike it?
> Ease in sorting and searching. If I were implementing such a filesystem,
> I'd store the names in a single case followed by a bitmap indicating
> which case to display.
>
Ah. But again, IMHO, Windows gets it right: ThisFile appears before
THISWASIT and after THISAPPLE. Doesn't that satisfy the sorting/searching
issue?
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of P S
> Sent: Thursday, December 31, 2009 3:12 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
>
> <PaulGB...@aim.com>wrote:
>
> > >OK, *not* trying to start a war, honestly curious: why do
> you dislike it?
> > Ease in sorting and searching. If I were implementing such
> a filesystem,
> > I'd store the names in a single case followed by a bitmap indicating
> > which case to display.
> >
>
> Ah. But again, IMHO, Windows gets it right: ThisFile appears before
> THISWASIT and after THISAPPLE. Doesn't that satisfy the
> sorting/searching
> issue?
Most LINUX applications also display the filenames with a case insensitive sort. Like the "ls" command. And Konquerer, Dolphin.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
P S
> wrote:
> Most LINUX applications also display the filenames with a case insensitive
> sort. Like the "ls" command. And Konquerer, Dolphin.
>
Good. I was starting to feel funny, holding up Windows as a shining
example...!
Paul Gilmartin
>> -----Original Message-----
>> [mailto:IBM-...@bama.ua.edu] On Behalf Of P S
>> Sent: Thursday, December 31, 2009 3:12 PM
>>
>> On Thu, Dec 31, 2009 at 3:44 PM, Paul Gilmartin wrote:
>>
>> > I'd store the names in a single case followed by a bitmap indicating
>> > which case to display.
>>
>> Ah. But again, IMHO, Windows gets it right: ThisFile appears before
>> THISWASIT and after THISAPPLE. Doesn't that satisfy the
>> sorting/searching
>> issue?
>
I wasn't proposing a different specification; merely envisioning
an implementation that would generate the result you observe
as efficiently as possible.
>Most LINUX applications also display the filenames with a case insensitive sort. Like the "ls" command. And Konquerer, Dolphin.
>
Errr... "case insensitive"? Would that mean that the ordering of
filenames which differ only in case is unpredictable, or is there
some residual case sensitivity?
-- gil
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Thursday, December 31, 2009 3:23 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
>
> >Most LINUX applications also display the filenames with a
> case insensitive sort. Like the "ls" command. And Konquerer, Dolphin.
> >
> Errr... "case insensitive"? Would that mean that the ordering of
> filenames which differ only in case is unpredictable, or is there
> some residual case sensitivity?
>
> -- gil
You're right it is not really insensitive. The lower case appears before the upper case of a given character. I.e. "apple" is before "Apple". My bad terminology. I guess the order is aAbBcCdD and so on.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
P S
> wrote:
> You're right it is not really insensitive. The lower case appears before
> the upper case of a given character. I.e. "apple" is before "Apple". My bad
> terminology. I guess the order is aAbBcCdD and so on.
>
While we're fantasizing (boy, are WE geeks!), that would have been an
interesting way for the characters to have been ordered in ASCII or EBCDIC
... think of how differently we might have done things! Of course, ORing
with x'40' to uppercase wouldn't work any more. But I guess you could OR
with x'01' instead, no? Or AND with x'FE' to lowercase? Hmm...
/me wanders off to tinker with the time machine again; maybe this time it
will work!
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of P S
> Sent: Thursday, December 31, 2009 3:37 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: CAPS Fantasia (was: argv for z/OS C++ batch)
>
> <John....@healthmarkets.com
> > wrote:
>
> > You're right it is not really insensitive. The lower case
> appears before
> > the upper case of a given character. I.e. "apple" is before
> "Apple". My bad
> > terminology. I guess the order is aAbBcCdD and so on.
> >
>
> While we're fantasizing (boy, are WE geeks!), that would have been an
> interesting way for the characters to have been ordered in
> ASCII or EBCDIC
> ... think of how differently we might have done things! Of
> course, ORing
> with x'40' to uppercase wouldn't work any more. But I guess
> you could OR
> with x'01' instead, no? Or AND with x'FE' to lowercase? Hmm...
>
> /me wanders off to tinker with the time machine again; maybe
> this time it
> will work!
If you get that time machine running, introduce UTF-8 instead of either plain ASCII or EBCDIC.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Anne & Lynn Wheeler
> While we're fantasizing (boy, are WE geeks!), that would have been an
> interesting way for the characters to have been ordered in ASCII or EBCDIC
> ... think of how differently we might have done things! Of course, ORing
> with x'40' to uppercase wouldn't work any more. But I guess you could OR
> with x'01' instead, no? Or AND with x'FE' to lowercase? Hmm...
>
> /me wanders off to tinker with the time machine again; maybe this time it
> will work!
recent thread from a.f.c on ebcdic & ascii
http://www.garlic.com/~lynn/2009k.html#26 A Complete History Of Mainframe Computing
that has a low of URL references ... why 360 became EBCDIC and not ASCII
EBCDIC and the P-BIT (The Biggest Computer Goof Ever)
http://www.bobbemer.com/P-BIT.HTM
other references from the same site:
HOW ASCII CAME ABOUT
http://www.bobbemer.com/ASCII.HTM
HOW ASCII GOT ITS BACKSLASH
http://www.bobbemer.com/BACSLASH.HTM
SIGNIFICANT ARTICLES ON ASCII
http://www.bobbemer.com/INSIDE-A.HTM
ASCII and the Mark of the Beast
http://www.bobbemer.com/666.HTM
ORIGIN OF THE ISO REGISTER FOR ASCII-ALTERNATE SETS
http://www.bobbemer.com/REGISTRY.HTM
from "EBCDIC and the P-BIT"
Who Goofed?
The culprit was T. Vincent Learson. The only thing for his defense is
that he had no idea of what he had done. It was when he was an IBM Vice
President, prior to tenure as Chairman of the Board, those lofty
positions where you believe that, if you order it done, it actually will
be done. I've mentioned this fiasco elsewhere
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
des...@verizon.net
> zos...@GMAIL.COM (P S) writes:
>> While we're fantasizing (boy, are WE geeks!), that would have been an
>> interesting way for the characters to have been ordered in ASCII or EBCDIC
>> ... think of how differently we might have done things! Of course, ORing
>> with x'40' to uppercase wouldn't work any more. But I guess you could OR
>> with x'01' instead, no? Or AND with x'FE' to lowercase? Hmm...
>>
>> /me wanders off to tinker with the time machine again; maybe this time it
>> will work!
>
> recent thread from a.f.c on ebcdic & ascii
> http://www.garlic.com/~lynn/2009k.html#26 A Complete History Of Mainframe Computing
>
> that has a low of URL references ... why 360 became EBCDIC and not ASCII
>
> EBCDIC and the P-BIT (The Biggest Computer Goof Ever)
> http://www.bobbemer.com/P-BIT.HTM
...
> from "EBCDIC and the P-BIT"
>
> Who Goofed?
>
> The culprit was T. Vincent Learson. The only thing for his defense is
> that he had no idea of what he had done. It was when he was an IBM Vice
> President, prior to tenure as Chairman of the Board, those lofty
> positions where you believe that, if you order it done, it actually will
> be done. I've mentioned this fiasco elsewhere
Who else goofed?
Once again, IBM. When they introduced the IBM PC they had 2 choices,
use someone else's chip, hardware, and OS and go with ASCII, or do the more
logical thing.
The more logical thing was to use their own chip making facilities and
build a mini-mainframe. Just like Wang did with their Wang/VS 5.
The machine could have been EBCDIC and retained most of the SYS/360
instructions. Only I/O would have to be simplified for the chips being
made back then.
Of course, they should have never let another company gain rights to the
OS.
What was the downside to this path? The only one I see is eventual
competition of IBM against IBM. So ultimately, greed at IBM destroyed
IBMs monopoly on computers.
At least, that's the way I see it.
Paul Gilmartin
>
>You're right it is not really insensitive. The lower case appears before the upper case of a given character. I.e. "apple" is before "Apple". My bad terminology. I guess the order is aAbBcCdD and so on.
>
and OpenSolaris:
509 $ ls -1
castor
Castor
castor bean
510 $
What does Linux do?
The technique appears to be: First sort as if entirely case-insensitive;
only then resolve any ties by considering the case of the characters.
Which is why I suggested keeping all alphabetic characters in a single
case, followed by a bitmap identifying the case of the characters.
Case-insensitive lookup would ignore the bitmap; case sensitive would
consider it.
-- gil
P S
> Which is why I suggested keeping all alphabetic characters in a single
> case, followed by a bitmap identifying the case of the characters.
> Case-insensitive lookup would ignore the bitmap; case sensitive would
> consider it.
>
OK, but that's implementation. From a usage standpoint, I'm still unclear
what you'd want changed in how Windows works. Or did I miss it?
Shane
> Actually, no. Not according to a couple dictionaries I glanced at,
> and OpenSolaris:
>
> 509 $ ls -1
> castor
> Castor
> castor bean
> 510 $
>
> What does Linux do?
Depends on LC_COLLATE - try setting it to "C" and see what happens.
Shane ...
Patrick Scheible
The IBM PC was a pretty late entrant into the PC market. ASCII was
already an established standard in most of the rest of the computing
world -- all the micros, lots of everything else. The younger crowd
made fun of IBM for having their own character set, and those were the
people they were trying to win over with the PC. I'm not sure the PC
world would have been interested in a micro-360. Micros were used for
one person at a time, not as an alternative to batch-processing
mainframes. Applications written to be run as batch processes don't
make good interactive applications. People who bought PCs wanted to
run spreadsheets and do word processing, not run payroll twice a
month. For one thing, no one's micros were reliable enough yet to
handle the payroll or the accounts receivable.
A significant part of the IBM PC's success was its open design.
Anyone could make add-ons or software for it. If it was closed, it
might not have been a success -- much like DEC's PC offerings.
Also, the IBM PC was cheap to design and produce, using off-the-shelf
made-in-Asia parts. If they'd designed all the parts themselves, it
would have been much more expensive. Again, like DEC's micros. The
IBM PC was already on the expensive side for a micro.
Yes, we see in retrospect that letting another company have the rights
to the OS was a huge mistake, especially since the hardware was open.
-- Patrick
John McKown
> >
> >You're right it is not really insensitive. The lower case appears before the upper case of a given character. I.e. "apple" is before "Apple". My bad terminology. I guess the order is aAbBcCdD and so on.
> >
> Actually, no. Not according to a couple dictionaries I glanced at,
> and OpenSolaris:
>
> 509 $ ls -1
> castor
> Castor
> castor bean
> 510 $
>
> What does Linux do?
>
> The technique appears to be: First sort as if entirely case-insensitive;
> only then resolve any ties by considering the case of the characters.
>
> Which is why I suggested keeping all alphabetic characters in a single
> case, followed by a bitmap identifying the case of the characters.
> Case-insensitive lookup would ignore the bitmap; case sensitive would
> consider it.
>
> -- gil
>
Same as Solaris.
Happy 2010 to all.
--
John McKown
Maranatha! <><
Paul Gilmartin
>
>Depends on LC_COLLATE - try setting it to "C" and see what happens.
>
Also, I RTFM and find:
9.2.9.3 "z/OS V1R10.0 DFSORT Application Programming Guide"
9.2.9.3 LOCALE
You can use the LOCALE
option to sort, merge, and compare character data based on collating rules in an active
locale; this enables you to obtain results with DFSORT that were previously possible
only through pre-processing or post-processing of your data. By eliminating such costly
processing, you can save time and processing resources.
-- gil
Paul Gilmartin
>On Fri, Jan 1, 2010 at 12:33 AM, Paul Gilmartin wrote:
>
>> Which is why I suggested keeping all alphabetic characters in a single
>> case, followed by a bitmap identifying the case of the characters.
>> Case-insensitive lookup would ignore the bitmap; case sensitive would
>> consider it.
>
>OK, but that's implementation. From a usage standpoint, I'm still unclear
>what you'd want changed in how Windows works. Or did I miss it?
>
I said earlier in the thread:
On Thu, 31 Dec 2009 15:23:18 -0600, Paul Gilmartin wrote:
>
>I wasn't proposing a different specification; ...
I said earlier in the thread:
On Thu, 31 Dec 2009 15:23:18 -0600, Paul Gilmartin wrote:
>
>I wasn't proposing a different specification; ...
>
I care little what NTFS does (I avoid Windows as much as possible).
However, when I mount a Samba share from a UNIX host and some
directory there contains "foobar", "FooBar", "foo,bar", etc.,
Explorer should display those names as faithfully as possible as
they would appear on the host platform, and clicking on each should
open the respective different file. Similarly, in CMD.EXE, the
commands (guessing):
type "foobar"
type "FooBar"
type "foo,bar"
should type the content of the respective file.
The implementation principle is simple: the API/GUI/CLI should
perform no transformation of the filename string, but pass it
unmodified to the filesystem (in this case, Samba client) which
should validate and resolve it.
Same should apply in z/OS.
.. gil
P S
> I said earlier in the thread:
>
Wow, I never saw this post...weird.
> However, when I mount a Samba share from a UNIX host and some
> directory there contains "foobar", "FooBar", "foo,bar", etc.,
> Explorer should display those names as faithfully as possible as
> they would appear on the host platform, and clicking on each should
> open the respective different file. Similarly, in CMD.EXE, the
> commands (guessing):
>
> type "foobar"
> type "FooBar"
> type "foo,bar"
>
> should type the content of the respective file.
>
Jeez, I *really* worry that it sounds like I'm being argumentative here, but
I don't mean to be -- AFAICT, this is how it works. So I'm still not sure
what it is you dislike about how Windows works now.
The only thing not clear is whether (given the above files and ONLY those
files existing):
type "FOOBAR"
should:
- work, typing one of the first two files
- say "Dude, pick a file"
- reformat the filesystem
:-)
Paul Gilmartin
>>
>> should type the content of the respective file.
>
>Jeez, I *really* worry that it sounds like I'm being argumentative here, but
>I don't mean to be -- AFAICT, this is how it works. So I'm still not sure
>what it is you dislike about how Windows works now.
>
different content in "foobar" and "FooBar"? Of course this may depend
on the version of the Samba client or server. IIRC, a couple years
ago, it showed one of the files as named on the host, and the other
as a generated 8.3 name. Now it shows both as named on the host, but
the behavior when clicking on one in Explorer is unpredictable.
>The only thing not clear is whether (given the above files and ONLY those
>files existing):
>type "FOOBAR"
>should:
>
>- work, typing one of the first two files
>- say "Dude, pick a file"
>- reformat the filesystem
>
>:-)
>
D) NOTA. Entering a dialog with the user is impractical when the
program might be running in background.
I'll stick to my principle: the application should pass "FOOBAR"
to the Samba client which should apply rules of the host system,
resulting in some form of "File not found." Other choices would
inevitably lead to astonishing behavior in some cases. If I write
to "FOOBAR", should it overwrite "FooBar" if it exists, but create
"FOOBAR" if it doesn't? I say, "No!" What happens in either case
if I go back to the host system and attempt to access FOOBAR?
CMS pipelines has a similar misbehavior. If I say:
PIPE literal Wombat | > Foo Bar A
it overwrites "Foo Bar A" if it exists; otherwise it creates
"FOO BAR A". Terrible design; perhaps even wore than TSO.
FTP generally has it right: it relies on lexical conventions of
the server file system. Samba should be allowed to do likewise.
-- gil
Quadibloc
> Wouldn't it have been glorious if the original definition of 6-bit
> BCD had specified lower case alphabetics _instead_of_ upper case?
> FORTRAN (excuse me) fortran programs would have been written in
> lower case; data set names would be lower case; and jcl would be
> lower case (but programmers might need to surround 'Upper Case'
> characters with apostrophes lest they be flagged as invalid). There
> would be no tendency for tso to convert to upper case, and there
> would be no need for an ASIS option. Nor would there be any
> particular use for the ispf editor's having a CAPS ON/OFF setting.
>
> Ah, well.
While there were some foreign countries in which single-case
teletypewriters did use lower case, this just was utterly unthinkable
in the English-speaking cultural environment.
John Savard
Quadibloc
> OK, *not* trying to start a war, honestly curious: why do you dislike it?
> (The 8.3 filenames are, of course, all uppercase, btw.) Why should it upper-
> or lowercase the filenames? What would that buy?
The problem is that it is inconsistent and confusing. If case is
visibly preserved, then that should imply case sensitivity. (Of
course, one could go one step further in the Windows direction and
"ignore case, _unless_ there are multiple files whose names differ
only in case".)
John Savard
Quadibloc
> Errr... "case insensitive"? Would that mean that the ordering of
> filenames which differ only in case is unpredictable, or is there
> some residual case sensitivity?
That issue would not arise, because duplicate file names are, of
course, illegal.
And they are duplicates if they are both referenced by the same input
string, even if they display differently.
John Savard
Quadibloc
wrote:
(quoting someone, attribution not found)
> > /me wanders off to tinker with the time machine again; maybe
> > this time it
> > will work!
>
> If you get that time machine running, introduce UTF-8 instead of either plain ASCII or EBCDIC.
That, I fear, is asking for far too much.
John Savard
Quadibloc
wrote:
> You're right it is not really insensitive. The lower case appears before the upper case of a given character. I.e. "apple" is before "Apple". My bad terminology. I guess the order is aAbBcCdD and so on.
The STRETCH did that, and it didn't work.
What you have to do is this:
apple -> APPLExxxxx
Apple -> APPLEXxxxx
to get dictionary order. So you basically want the case distinction to
be in a "resource fork" of the string.
John Savard
Patrick Scheible
> On Dec 31 2009, 2:28=A0pm, John.McK...@HEALTHMARKETS.COM (McKown, John)
> wrote:
>
> > You're right it is not really insensitive. The lower case appears before =
> the upper case of a given character. I.e. "apple" is before "Apple". My bad=
> terminology. I guess the order is aAbBcCdD and so on.
>
> The STRETCH did that, and it didn't work.
>
> What you have to do is this:
>
> apple -> APPLExxxxx
>
> Apple -> APPLEXxxxx
>
> to get dictionary order. So you basically want the case distinction to
> be in a "resource fork" of the string.
Every printed dictionary I've ever seen ignores case. If they end up
with two words that are spelled the same way, which files first is
decided by other characteristics, such as part of speech, date at
which the word originated, or how frequently the word is used.
-- Patrick
Don Williams
allowed file names to be font sensitive, so that font characteristics like
bold, italics, underline, color, etc. made a difference. Then foo [in blue],
foo [in red], foo [in green] would be different files. Just think how
expressive the user's file names could be. Allowing the user specify the
font characteristics to be used when displaying/listing file names might be
strange, but requiring font characteristics to match in order to manipulate
a file would be a nightmare in Technicolor.
With that insanity in mind, I'm happy with a file system that keeps my case
intact when it displays my files names, but does not force me to use the
same case to manipulate my files (that's expressive enough for me).
Paul Gilmartin
>Imagine extending case sensitivity to font sensitivity. If the file system
>allowed file names to be font sensitive, so that font characteristics like
>bold, italics, underline, color, etc. made a difference. Then foo [in blue],
>foo [in red], foo [in green] would be different files. Just think how
>expressive the user's file names could be. Allowing the user specify the
>font characteristics to be used when displaying/listing file names might be
>strange, but requiring font characteristics to match in order to manipulate
>a file would be a nightmare in Technicolor.
>
>With that insanity in mind, I'm happy with a file system that keeps my case
>intact when it displays my files names, but does not force me to use the
>same case to manipulate my files (that's expressive enough for me).
>
But you may be showing an anglophone bias. If I were a native
Russian speaker, I might feel slighted if I were required to name
my files in ISO Latin 1 rather than Cyrillic.
I just tried, and on OS X and OpenSolaris I was able to create
directories, both named Документы (I wonder what LISTSERV
will do with that; I'm posting from the web interface). I don't
think I'd be comfortable if they were conflated with either
"Documents" or "Dokumenty". So, in some environments,
font sensitivity is with us; I believe for better rather than for
worse as long as the file system supports multiple fonts.
(OS X and OSol both appear to have used UTF-8. I wonder
what Samba would do. I shudder to think what a z/OS catalog
would do.)
-- gil
Shmuel Metz , Seymour J.
at 10:13 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>What objective would be served by converting to lower case?
Handling mixed-case input. Even if you tell people not to do it, you can't
stop them.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Shmuel Metz , Seymour J.
at 02:44 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Long ago, I experimented with STOW from assembler. It uncomplainingly
>creates member names in mixed case, and worse.
Worse, SMP depended on being able to do that.
Shmuel Metz , Seymour J.
12/31/2009
at 12:08 PM, "Thompson, Steve" <Steve_T...@STERCOMM.COM> said:
>I think that the case munging of some things was due to the 3277.
Didn't it go back to the 1050, the 2260, the 2740 and the TTY?
>And the caps lock sucked in that it wasn't a caps lock, but a shift
>lock which affected the numbers vs. special characters on the
>top row.
De gustibus. I though that caps lock was a step backward from shift lock.
Certainly when my editor has the ability to automatically upper case my
input the caps lock key doesn't help me at all.
Quadibloc
> Imagine extending case sensitivity to font sensitivity. If the file system
> allowed file names to be font sensitive, so that font characteristics like
> bold, italics, underline, color, etc. made a difference.
That would be horrible.
However, I would have considered it an improvement if Unicode
allocated distinct code positions to small capitals, just as ASCII
does to upper and lower case, so that a single font can include small
capitals.
Doing this for italic and boldface also would help with the entry of
Pascal programs... that would, of course, be the prerequisite to the
"insanity" you criticize.
However, while an italic "x" and a normal "x" would be two distinct
characters, and thus there could be sensitivity to the distinction
between them, true font sensitivity would still be quite impossible.
Whether an "x" is a Caslon x, or a Baskerville x, or a Times New Roman
x, or a Century Expanded x, or a Caledonia x is something that is
applied after the fact of the character string in the presentation
layer. So I think we are quite safe from programs becoming font-
sensitive (or, more properly, typeface-sensitive).
John Savard
jmfbahciv
backup and BACKUP.
/BAH
Tony Harminc
> On Thu, 31 Dec 2009 15:28:16 -0600, McKown, John wrote:
>>
>>I guess the order is aAbBcCdD and so on.
>>
> Actually, no. �Not according to a couple dictionaries I glanced at,
> and OpenSolaris:
>
> � �509 $ ls -1
> � �castor
> � �Castor
> � �castor bean
> � �510 $
>
> What does Linux do?
>
> The technique appears to be: First sort as if entirely case-insensitive;
> only then resolve any ties by considering the case of the characters.
>
> Which is why I suggested keeping all alphabetic characters in a single
> case, followed by a bitmap identifying the case of the characters.
> Case-insensitive lookup would ignore the bitmap; case sensitive would
> consider it.
You really can't do a proper text sort by ordering individual byte
values. The usual approach, pioneered about 15 years ago by some smart
people at IBM's National Language Centre in Toronto, and one smart guy
in the Quebec government, is to assign separate sort keys to a string,
based on the character value, the case, the accent, and "special"
weighting. Then you sort those keys instead of the original string. Of
course you can precalculate the sort keys or do them on the fly,
depending on the performance and storage tradeoffs.
Sorting is a cultural thing (where "culture" can include C programming
as much as French-in-France, French-in-Canada, English, German, etc.)
And each culture may have multiple sort orders appropriate for
different circumstances. For example French dictionaries have a
different order from French phonebooks; a French phonebook user may
expect to find the name duPont under P, not under D. Even in English,
where do you expect to find castor-oil in the list above? Surely the
hyphen should be given lower weighting than even the letters that
follow it, so that it comes out after castor bean. How about Caesar vs
C�sar or Noel vs No�l? Google search knows that they are the same
thing, but Gmail flunks the latter in its spelling checker. What does
the "ls" command think?
Tony H.
Paul Gilmartin
>
>Sorting is a cultural thing (where "culture" can include C programming
>as much as French-in-France, French-in-Canada, English, German, etc.)
>And each culture may have multiple sort orders appropriate for
>different circumstances. For example French dictionaries have a
>different order from French phonebooks; a French phonebook user may
>expect to find the name duPont under P, not under D. Even in English,
>where do you expect to find castor-oil in the list above? Surely the
>hyphen should be given lower weighting than even the letters that
>follow it, so that it comes out after castor bean. How about Caesar vs
>C�sar or Noel vs No�l? Google search knows that they are the same
>thing, but Gmail flunks the latter in its spelling checker. What does
>the "ls" command think?
>
DFSORT). With OpenSolaris's default (whatever):
506 $ ls -1
Документы
Caesar
C�sar
castor
Castor
castor bean
castor-oil
Noel
No�l
507 $
(Pasted into browser window with UTF-8 selected.)
Are you suggesting that diacritical marks should be
considered embellishments, lacking semantic significance?
Ask a Spanish speaker whether "a�o" is the same as "ano".
-- gil
P S
> Ask a Spanish speaker whether "a�o" is the same as "ano".
>
No, they're different letters. It may be clear from context, but the two are
no more the same than "awe" and "ave" in English. A better question might be
to ask a French speaker whether "saute" and "saut�" are the same.
Paul Gilmartin
On Sat, 2 Jan 2010 15:26:04 -0500, Tony Harminc wrote:
>
> Sorting is a cultural thing (where "culture" can include C programming
> as much as French-in-France, French-in-Canada, English, German, etc.)
> And each culture may have multiple sort orders appropriate for
> different circumstances. For example French dictionaries have a
> different order from French phonebooks; a French phonebook user may
> expect to find the name duPont under P, not under D. Even in English,
> where do you expect to find castor-oil in the list above? Surely the
> hyphen should be given lower weighting than even the letters that
> follow it, so that it comes out after castor bean. How about Caesar vs
> Cæsar or Noel vs Noël? Google search knows that they are the same
> thing, but Gmail flunks the latter in its spelling checker. What does
> the "ls" command think?
>
OK. As Shane suggested, it depends on Locale setting (same for
DFSORT). With OpenSolaris's default (whatever):
506 $ ls -1
Документы
Caesar
Cæsar
castor
Castor
castor bean
castor-oil
Noel
Noël
507 $
(Emailed to list with:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
)
Are you suggesting that diacritical marks should be
considered embellishments, lacking semantic significance?
Ask a Spanish speaker whether "año" is the same as "ano".
-- gil
P S
> I'm trying this again, with a different technique:
>
Da, "document" in Cyrillic came through that time, rather than as &whatever.
Lindy Mayfield
Paul Gilmartin
>
>Da, "document" in Cyrillic came through that time, rather than as &whatever.
>
An update (I hope):
520 $ ( LANG=en_US.UTF-8 && ls -1 foo )
ДОКУМЕНТЫ
Документы
ДОКУМЕНТЫ x
Документы x
ano
año
ano x
año x
Caesar
Cæsar
Caesar x
Cæsar x
castor
Castor
castor bean
castor-oil
Noel
Noël
Noel x
Noël x
521 $ ( LANG=es.UTF-8 && ls -1 foo )
ДОКУМЕНТЫ
Документы
ДОКУМЕНТЫ x
Документы x
ano
ano x
año
año x
Caesar
Cæsar
Caesar x
Cæsar x
castor
Castor
castor bean
castor-oil
Noel
Noël
Noel x
Noël x
522 $
... so it DTRT in Spanish. Interesting that it DTRT with Cyrillic,
even when LANG=en_US. And that in Cyrillic majuscule precedes
minuscule.
-- gil
Charlie Gibbs
writes:
> Patrick Scheible wrote:
>
>> Quadibloc <jsa...@ecn.ab.ca> writes:
>>
>>> On Dec 31 2009, 2:28=A0pm, John.McK...@HEALTHMARKETS.COM
>>> (McKown, John) wrote:
>>>
>>>> You're right it is not really insensitive. The lower case appears
>>>> before the upper case of a given character. I.e. "apple" is before
>>>> "Apple". My bad terminology. I guess the order is aAbBcCdD and so
>>>> on.
>>>
>>> The STRETCH did that, and it didn't work.
>>>
>>> What you have to do is this:
>>>
>>> apple -> APPLExxxxx
>>>
>>> Apple -> APPLEXxxxx
>>>
>>> to get dictionary order. So you basically want the case distinction
>>> to be in a "resource fork" of the string.
Resource fork? Way too much complexity. Just use a case-insensitive
string comparison routine, which will work on any data without requiring
an attribute bureaucracy.
>> Every printed dictionary I've ever seen ignores case. If they end up
>> with two words that are spelled the same way, which files first is
>> decided by other characteristics, such as part of speech, date at
>> which the word originated, or how frequently the word is used.
>
> But what about indexing? There is a huge difference between
> backup and BACKUP.
Do a case-insensitive sort that uses case as a tie-breaker.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Tony Harminc
> OK. �As Shane suggested, it depends on Locale setting (same for
> DFSORT). �With OpenSolaris's default (whatever):
>
> 506 $ ls -1
> Документы
> Caesar
> C�sar
> castor
> Castor
> castor bean
> castor-oil
> Noel
> No�l
> 507 $
>
> (Pasted into browser window with UTF-8 selected.)
Looks good (both display and order), except for that first one.
> Are you suggesting that diacritical marks should be
> considered embellishments, lacking semantic significance?
Certainly not - I can't see that I suggested anything at all like
that. Generally the non-letter characters such as the hyphen I used in
castor-oil do have lower sort significance than the letters, and the
diacritics used standalone (stand-alone?) behave the same way. But
diacritics combined with a letter are a different matter. Also their
meaning and treatment varies between languages/locales, and further,
some of what speakers of one language may think of as letter+diacritic
are in fact separate letters in another. (We would be annoyed, to say
the least, if a speaker of another language insisted that English R
was just P with a diacritic attached to the bottom right.)
The French rules are interesting in that they require the accents on
letters to be weighted from right to left, and it turns out that this
rule doesn't offend any other western European languages *when used
for those letter+accent combinations allowed in French* , so it
generally gets used for all of them. The classic French sort test
(classic as in IBM Redbook circa 1995) is something like:
cote
Cote
cot�
Cot�
c�te
c�t�
C�t�
What does your ls think of these?
> Ask a Spanish speaker whether "a�o" is the same as "ano".
Yeah, yeah - Feliz ano nuevo to you too. The operation wasn't too
uncomfortable? Whether n and � are different letters in Spanish is
another matter, and one I am not competent to pronounce on. Certainly
a and � are the same letter in Spanish, even if the meaning of some
words is changed when one is substituted for the other.
Spanish had a grand, uh, reordering some years ago in the name of
"making things easier for computers" just about at the same time that
the IBMers figured out how to do it right. So ll used to sort
independently of single l words, but now it sorts after lk and before
lm, as it does in English. I believe some systems support an "old
Spanish" locale with ordering that puts llama after zapata.
Well, we've moved a fair way from argv for C++...
Tony H.
Gerhard Postpischil
> Spanish had a grand, uh, reordering some years ago in the name of
> "making things easier for computers" just about at the same time that
> the IBMers figured out how to do it right. So ll used to sort
> independently of single l words, but now it sorts after lk and before
> lm, as it does in English. I believe some systems support an "old
> Spanish" locale with ordering that puts llama after zapata.
You picked a really horrid example. I was taught that "llama" is
pronounced with an "l" sound (old Quechua), but according to
wiki, modern Quechua copied the "y" sound from Spanish.
Webster's shows both as valid. And where in this sequence would
you put a Welsh "ll"? <g>
Gerhard Postpischil
Bradford, VT
Shmuel Metz , Seymour J.
at 02:33 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Are you suggesting that diacritical marks should be
>considered embellishments, lacking semantic significance?
I suspect that he's suggesting transforming to a locale-dependent
canonical form for sorting.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 05:41 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>So, in some environments, font sensitivity is with us;
ITYM code-page sensitivity, and if we ever switch to Unicode[1] then that
issue should disappear as well.
>(OS X and OSol both appear to have used UTF-8.
In which case your Russian file names should be rendered properly without
font sensitivity.
[1] Raw, e.g., UCS-4, or with a transform, e.g., UTF-8
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Don Williams
English or rather American English. While I did ponder about code pages for
other languages, I felt that any comment would probably be opening my mouth
and inserting my foot. It seems I managed to do that anyway.
Early in my career, I was stationed in Germany. I learned that foreign
programmers were required to program in "English", because the major
languages of the time (COBOL, FORTRAN, etc.) all used keywords spelled in
English. As a young kid, that seemed quite unfair, but when I asked those
programmers they thought nothing of it. They inferred that my question was
trivial and even the thought of supporting multi-lingual programming
languages would be counter-productive. Of course, they spoke English, so any
"English" keywords posed no problem; so they were likely biased. This kind
of reasoning, seems to lead to the question: is imposing a standard code
page that only contains ISO Latin characters fair? No, but it is expedient.
Of course, most code pages have many characters with no standard translation
to other code pages. Therefore allowing multiple code pages is likely to
have challenges. However, fonts and code pages are not quite the same thing.
Fonts can have characteristics like color, boldness, size, etc. that are
independent of the code page. Based on the assumption that fonts and code
pages are different (perhaps a bad assumption) I figured that you could
"translate" all colors to black, remove boldness, etc. such that those kinds
of font characteristics would be independent of the code page. So when you
ignore font characteristics, a file called foo [in blue] would be same file
as foo [in red], etc. It might mean that the file system might need to have
two fields, one without font attributes for functional access, and another
with font attributes for display purposes. Of course, having two fields to
keep in sync is not expedient, but it would allow people to be expressive.
Case is different. As best as I can tell, case is not really a font
attribute. Case is a character attribute. Changing the case of a character,
is really changing the character; whereas changing the color of a character
does not. I don't know, but I expect there are many languages that don't
have the concept of case. I expect that in some languages, case is
important. The meaning of a word can significantly change when the case is
changed. In other languages, changing case may be insignificant.
Has it been discussed what to do about writing orientation. Languages like
English are left to right, top to bottom. I believe that Chinese can be
bottom to top, right to left. I expect some other languages have still
different orientations.
My conclusion, there is probably no solution that will make everybody happy.
Therefore, a choice than is only expedient is probably the best we can do.
Don
"Make everything as simple as possible, but no simplier." - Albert Einstein
Paul Gilmartin
>On Fri, Jan 1, 2010 at 11:01 AM, Paul Gilmartin wrote:
>
>> However, when I mount a Samba share from a UNIX host and some
>> directory there contains "foobar", "FooBar", "foo,bar", etc.,
>> Explorer should display those names as faithfully as possible as
>> they would appear on the host platform, and clicking on each should
>> open the respective different file. Similarly, in CMD.EXE, the
>> commands (guessing):
>>
>> type "foobar"
>> type "FooBar"
>> type "foo,bar"
>>
>> should type the content of the respective file.
>
>Jeez, I *really* worry that it sounds like I'm being argumentative here, but
>I don't mean to be -- AFAICT, this is how it works. So I'm still not sure
>what it is you dislike about how Windows works now.
>
Nope. I've created a nest of directories which displays
on Unix (correctly):
...
castor
marker
Castor
Marker
...
With Windows XP explorer (and I'm not sure what Samba server
and client) I see:
...
Castor
Marker
castor
Marker
...
Note that "Marker" appears in both directories, not "marker"
which should appear in "castor".
This is just plain wrong; deceptive; dangerous. If Windoze
can't handle the situation, it should at least give me the
courtesy of an error message.
-- gil