If I recall correctly, for Commodores, the equivalent of the disk operating system was handled by the drive itself. If you wanted to do anything beyond a LOAD or a SAVE, you were effectively opening the device then sending a command to the device. The exception was getting a directory, which used the LOAD command (as described earlier) rather than a dedicated command. In my opinion, it is accurate to describe loading a special file in order to retrieve a directory listing as a trick.

Looking at the Apple II and Commodore 64, I think it is fair to say that while the BASIC environments supported varying degrees of disk command they were quite different from what we think of as command interpreters. With Unix shells, anything you can enter into a shell script can be executed from the command line, and vice versa. If memory serves me correctly, anything that could be done from the MS/PC-DOS command line could be done from a batch file (though I don't recall if the opposite is true).

I did not mean it’s a trick users applied, I meant that the developers of the 1541 DOS implemented this very trick. You load a textual representation of the directory into memory as a BAISC program, that’s pretty funky.

And it was precisely done because the straightforward way, which would have been something like opening a sequential channel with a dedicated directory listing command and reading out from it, would have been immensely awkward under BASIC 2.0. Hence the magic “$” program.

It leads to the catch-22 that when saving a BASIC program you cannot tell which filenames are already in use, since you cannot get a directory listing without losing the current BASIC program in memory. All you can do is guess a filename that is probably free.