• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

A curious case of case.

Started by ddan, 2008.10.08, 19:24:49

Previous topic - Next topic

ddan

In looking at an apparent bug in my file selector, I found a strange difference in case:

OS/2 Wed 10-08-2008 10:59:16.38 C:\>dir os*

The volume label in drive C is OS2.
The Volume Serial Number is A9A7:D414.
Directory of C:\

4-15-08   1:07p     <DIR>       11177  OS2      <<< NOTE DIRECTORY NAME IS UPPER CASE
4-15-08   1:37p     <DIR>           0  os2tk45
        2 file(s)          0 bytes used
                   3761091 K bytes free

OS/2 Wed 10-08-2008 10:59:20.21 C:\>cd os2

OS/2 Wed 10-08-2008 10:59:22.68 C:\os2>       <<< AND NOW IT'S LOWER CASE!

Can anyone explain HOW this can even be?

It SEEMS to apply only to the \OS2 directory; haven't found any others with case different depending on where you look at it from. My thought is that it's somehow related to the volume name (OS2).

rudi

Try "cd OS2" instead of "cd os2" and see what happens ...

Pete

Hi ddan


Seems to be the "standard" as it happens on several systems, here is 1example:-

[H:\]dir os*

The volume label in drive H is eCS1.2R.
The Volume Serial Number is 7353:D5BF.
Directory of H:\

6-10-08  3:16p         <DIR> 11,126 ----  OS2
.
.
.

       13 file(s)   1,634,407 bytes used
                    977,289,216 bytes free

[H:\]cd os2

[H:\os2]


And a different 1 :-

[H:\] dir mpt*

The volume label in drive H is eCS1.2R.
The Volume Serial Number is 7353:D5BF.
Directory of H:\

17-04-08  1:06p         <DIR>    727 ----  MPTN
        1 file(s)           0 bytes used
                    977,289,216 bytes free

[H:\]cd mptn

[H:\mptn]


Now watch this:-

[H:\]CD MPTN

[H:\MPTN]


Looks like the case depends on what the user is using  :-)


Hope that solves the mystery  :-)

Pete


ddan

No, demonstrating the effect doesn't SOLVE any mystery. When you logged into a directory, it should show the actual text of the directory name as stored on the drive, not as you HAPPEN to have typed it in.

And, the problem is the effect on my program, which needs to match the directory name while preserving case for readibility, and it will likely be started IN a directory that I've used only lower case to get to. Rexx directory(), then, gets a non-actual name of the directory! Looks as though to dodge the buggish effect I'd have to kludge in an upcase of everything to compare, which ought not be necessary, wouldn't be if the actual text off the drive were used for the path.

Radek

IMO, it's not a bug, it's rather a "flexibility".
File names are case insensitive in OS/2. Therefore, 'mydir', 'MYDIR', and 'MyDir' are the same object. The operating system allows you to use all these names and it will follow your choice but all these names will always reference the same directory. It will also store your choice in system data tables on the HD so that when you create a 'SomeDir' directory, you will have 'SomeDir' and not 'SOMEDIR' but 'SOMEDIR' is equally good as 'SomeDir' for the operating system.
Therefore, always uppercase (or lowercase) all filenames before doing something with them (comparing, searching, sorting, and so on).

ddan

Yes, I LIKE case-insensitive on the command line, wouldn't have it otherwise.

Let me clarify: the BUG is that text as I happened to type is passed to the Rexx function, rather than the ACTUAL directory name. I ought to be able to rely on a function call getting the ACTUAL text off the drive. That this isn't so is the mystery. -- I was in fact relying on the program call RATHER than any typing, and in the application it's definitely an annoying anomaly.

Fortunately, except for the one case where it locates the highlight one place off if I start in an "os2", "Os2", or "oS2" (but not the "OS2") directory, will probably be tolerable, so doubt I'll ever do the rather extensive uppercasing.