the number of files in a directory minus the dot and double-dot entries if trying to determine the total number of directories (and possibly files) in a directory? Or maybe to be more precise about exactly what I am trying to accomplish, I would like @Files (or a function that I write to "replace" it) to return the same number for the "root" of a "genuine", physical drive (or RAM disk) as it does for a drive letter which is Subst'd to a subdirectory of a drive which means that the those two pseudo-directories would should not be counted (although the only file name "patterns" that I am aware of that would count them are "*" and "." assuming that the other parameter(s) are such that directories are being counted at all, although that doesn't help as far as I can tell because any "pattern" that would exclude the dot and double-dot entries would exclude other directory entries as well). (I think the reasons for this have been "addressed" on this forum in the past as to why there is no "equivalent" of the "/H" parameter that is available for both the "Dir" and "PDir' commands (but with precisely "opposite" meanings) for the "@Files" function, but as far as I can tell that is the case.) And I am not aware of any file-name pattern that would count all of the directories in a directory except for the dot and double-dot entries, just as there are also no "attributes" that I can think of that would exclude just the dot and double-dot entries, either. And in terms of subst'd drives, I can't really assume that a subst'd drive letter will be "connected to" a subdirectory of another drive rather than the root directory of another drive. While I wouldn't call this exactly "vital", I do consider important for the application that I intend to use it for.
Just as a note on why I would ever subst one drive letter to the root directory of another drive letter, that is now the completely "normal" situation for me. That is because, as I have often mentioned on this forum previously, I use and am heavily dependent on in a whole number of ways on a RAM disk, which I have been using for a period of several years; and when I installed the RAM-disk software I chose "Z" as the drive letter both because it would be the easiest to remember and the most "out of the way", so to speak. Well I had a need to get and install the latest version of that software in recent history (I no longer remember exactly why; bad memory again) and the latest version of the software did not let me assign a drive letter of my choice in the installation procedure, unlike the previous version. (In fact, it "came up" as drive "J:", the next available drive letter, and I could find no way to change that drive letter to anything else.) Well, this was simply put, totally unacceptable to me both because I had years of habits that made me automatically type "Z:" in various situations and the fact that I had a fair number of batch files (and C++ programs) that had Z: intentionally hard-coded in them because I absolutely did not want them to do anything to a disk that wasn't a RAM disk because, simply put, they could be very destructive and that "destruction" wouldn't really be that big of deal (other than being possibly somewhat inconvenient) if done to my RAM disk whereas it could be catastrophic if done to a real, physical, hard disk. So my "solution" to the above was simple: I have code in my Windows "Startup" procedure that assigns drive letter Z: to drive letter J:, both "administratively" and not administratively ("administrative" drive letters are not "seen" by non-administrative tasks, and vice versa), so the fact that drive "Z:" is really drive "J:" is almost completely "transparent" to me. (I have a couple of (C++) programs that I've written over the years that "translate" subst'd drive letters to their "real" locations for various reasons (mostly having to do with "safety" and/or "paranoia"), and while I suppose I could "steal" that code for this purpose, I'd really rather not because I am trying to get out of the C++ "habit" entirely.)
Just as a note on why I would ever subst one drive letter to the root directory of another drive letter, that is now the completely "normal" situation for me. That is because, as I have often mentioned on this forum previously, I use and am heavily dependent on in a whole number of ways on a RAM disk, which I have been using for a period of several years; and when I installed the RAM-disk software I chose "Z" as the drive letter both because it would be the easiest to remember and the most "out of the way", so to speak. Well I had a need to get and install the latest version of that software in recent history (I no longer remember exactly why; bad memory again) and the latest version of the software did not let me assign a drive letter of my choice in the installation procedure, unlike the previous version. (In fact, it "came up" as drive "J:", the next available drive letter, and I could find no way to change that drive letter to anything else.) Well, this was simply put, totally unacceptable to me both because I had years of habits that made me automatically type "Z:" in various situations and the fact that I had a fair number of batch files (and C++ programs) that had Z: intentionally hard-coded in them because I absolutely did not want them to do anything to a disk that wasn't a RAM disk because, simply put, they could be very destructive and that "destruction" wouldn't really be that big of deal (other than being possibly somewhat inconvenient) if done to my RAM disk whereas it could be catastrophic if done to a real, physical, hard disk. So my "solution" to the above was simple: I have code in my Windows "Startup" procedure that assigns drive letter Z: to drive letter J:, both "administratively" and not administratively ("administrative" drive letters are not "seen" by non-administrative tasks, and vice versa), so the fact that drive "Z:" is really drive "J:" is almost completely "transparent" to me. (I have a couple of (C++) programs that I've written over the years that "translate" subst'd drive letters to their "real" locations for various reasons (mostly having to do with "safety" and/or "paranoia"), and while I suppose I could "steal" that code for this purpose, I'd really rather not because I am trying to get out of the C++ "habit" entirely.)