RunCPM can't execute COM file that's definitely there -- filename case issue?

[Kroc]

The filenames are lowercase on the filesystem, but whilst RunCPM cannot list the files, it can't execute them regardless of case typed!

[MockbaTheBorg]

I see it happens on Linux (maybe Mac also, and others).
I wonder ... if we have 'xpto.COM', 'XPTO.com' and 'xpto.com' in the same folder, which are perfectly fine Linux names, which one should RunCPM execute when you type XPTO?
The answer is: none! because none of them are XPTO.COM.
Specifically for this situation I had added the following to our readme:
All the letters for folders/subfolders and file names should be kept in uppercase, to avoid any issues of case-sensitive filesystems compatibility.
I can´t prevent the underlying operating system to give me all the names when I scan its directories.
So in this case I suggest just use uppercase across the board.
We can call it a filesystem "limitation".

[Kroc]

Okay, that's fair but I wish I had a choice of uppercase vs. lowercase. Perhaps if a file doesn't exist in the all-uppercase form, check for the all-lowercase form?

[SEGStriker]

What if the subdirectory has both upper and lower characters, for example ProgAll? So, no way for such a smart check.

[Kroc]

It wouldn't have to handle all possibilities -- just ALL CAPS and all lower as the two predominate styles.

[SEGStriker]

I would say that one of predominate styles is to have capital letter at the beginning. Which means it depends on the logic.

[MockbaTheBorg]

I will actually see if I can make it use the first one. Doesn't matter caps combination.
Then it becomes up to us to prevent duplicates.
But it would ignore case.
I think this would be the best behavior.

[feilipu]

Just to point out the obvious, the repo is RunCPM. Allowing lowercase would make it RunSomethingLikeCPMish.

CPM expects all uppercase filenames, and many original utilities rely on this. So imho, keep to the standard of CPM 2.2 or later.

[Kroc]

Nothing changes within the CP/M environment, this would be entirely a convenience on the host side

[MockbaTheBorg]

Yes. That would be just to fix (or standardize) on the host side. The cp/m will continue to be uppercase.

…

On Sun, Feb 9, 2025, 8:09 PM Kroc Camen ***@***.***> wrote: Nothing changes within the CP/M environment, this would be entirely a convenience on the host side — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD74NC2XKMSTHPFXXICKV3L2O7327AVCNFSM6AAAAABWYDE776VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBWG4YTMMBVGM> . You are receiving this because you commented.Message ID: ***@***.***>

[SEGStriker]

On the host side it is fully OS dependent - DOS/Windows doesn't really care about the case (Windows can use both upper and lowercase in file names, but still doesn't really care). Simple example:

C:>dir f*
Volume in drive C is OS

Directory of C:\

01/22/2025 04:45 PM

Files
0 File(s) 0 bytes
1 Dir(s) 229,678,669,824 bytes free

C:>dir F*
Volume in drive C is OS

Directory of C:\

01/22/2025 04:45 PM

Files
0 File(s) 0 bytes
1 Dir(s) 229,678,620,672 bytes free

As shown, it will find "Files" in both cases, even though it contains one capital letter and the rest are lowercase. Same in more complex situations.
But in Linux it is completely the opposite - it really cares about upper/lowercase. So in theory we could have /Files, /files and /FILES in one directory:

[root@server]# mkdir files
[root@server]# mkdir Files
[root@server]# mkdir FILES
[root@server]# ls -la
total 5
drwxr-xr-x 6 root root 99 Feb 10 01:39 .
dr-xr-x---. 17 root root 4096 Dec 12 20:09 ..
drwxr-xr-x 2 root root 6 Feb 10 01:39 files
drwxr-xr-x 2 root root 6 Feb 10 01:39 Files
drwxr-xr-x 2 root root 6 Feb 10 01:39 FILES

This is a real test, not just manipulation :)
So, how will RunCPM distinguish these 3 directories if all of them exist and are converted by the emulator to uppercase?

[MockbaTheBorg]

RunCPM ignores directories, it only pays attention to files. And in case of the files it will be the first found. (That is my plan at least) And it will ignore case. Leaving up to us to prevent duplicates. (Unless Linux glob calls prevent me from doing it)

…

On Sun, Feb 9, 2025, 8:46 PM Stanislav Georgiev ***@***.***> wrote: On the host side it is fully OS dependent - DOS/Windows doesn't really care about the case (Windows can use both upper and lowercase in file names, but still doesn't really care). Simple example: C:>dir f* Volume in drive C is OS Directory of C:\ 01/22/2025 04:45 PM Files 0 File(s) 0 bytes 1 Dir(s) 229,678,669,824 bytes free C:>dir F* Volume in drive C is OS Directory of C:\ 01/22/2025 04:45 PM Files 0 File(s) 0 bytes 1 Dir(s) 229,678,620,672 bytes free As shown, it will find "Files" in both cases, even though it contains one capital letter and the rest are lowercase. Same in more complex situations. But in Linux it is completely the opposite - it really cares about upper/lowercase. So in theory we could have /Files, /files and /FILES in one directory: ***@***.***# mkdir files ***@***.***# mkdir Files ***@***.***# mkdir FILES ***@***.***# ls -la total 5 drwxr-xr-x 6 root root 99 Feb 10 01:39 . dr-xr-x---. 17 root root 4096 Dec 12 20:09 .. drwxr-xr-x 2 root root 6 Feb 10 01:39 files drwxr-xr-x 2 root root 6 Feb 10 01:39 Files drwxr-xr-x 2 root root 6 Feb 10 01:39 FILES This is a real test, not just manipulation :) So, how will RunCPM distinguish these 3 directories if all of them exist and are converted by the emulator to uppercase? — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD74NC22WOZ2CUYFHZY564T2PAAITAVCNFSM6AAAAABWYDE776VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBWG42DKOJUGU> . You are receiving this because you commented.Message ID: ***@***.***>

[SEGStriker]

Yeah, it is same with files. Directories are nothing else but special kind of files, you know that.
OK, whatever you decide.

[MockbaTheBorg]

What I meant is. The only directories that matter are the "drive" ones. Any directories inside those are ignored (it is a bug if they aren't). So if you create a XPTO.COM folder, it will be like if it is not there.

…

On Sun, Feb 9, 2025, 8:55 PM Stanislav Georgiev ***@***.***> wrote: Yeah, it is same with files. Directories are nothing else but special kind of files, you know that. OK, whatever you decide. — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD74NC4NZFRFOUONDJZPLWT2PABI3AVCNFSM6AAAAABWYDE776VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBWG42TEOJVHA> . You are receiving this because you commented.Message ID: ***@***.***>

[MockbaTheBorg]

Ok ... upon revisiting the disk code after all these years the conclusion is:
can´t be done.
RunCPM treats all filenames internally as uppercase, as it should be.
So, even though I am using the glob() function to collect the directory on Linux in a case insensitive manner today (which means a:v65.com appears as A:V65.COM when you DIR), when you try to run that program it will ultimately be converted to a fopen() request to ./A/0/V65.COM, which doesn´t exist.
To make that exist it would require RunCPM to either work with the names internally everywhere without converting them to uppercase or keep a translation table somehow (which is a different can of worms, as there might be multiple instances of the "same" name with different case combinations.
It is a lot of code to modify for what is actually a documented "limitation" specific to Linux (remember, RunCPM was born on Windows, Linux is already a port of it).
So at this point, for the specific Linux use case I can only offer one proposition:
Have your CPM filesystem created in an image or USB device formatted with vfat, cd to there and run RunCPM. It will be case insensitive now and everything will work.
I actually use the USB solution, so I can move my CP/M collection between my Windows desktop, my Linux laptop and bring it with me to work when I want to procrastinate.