Random thought: the forward-slash switch character as used by DOS programs (e.g. chkdisk.exe /f /whatever) is actually a better choice than the dash used by UNIX programs. The forward slash is not a valid character in a DOS filename, so a glob will not expand to include a forward slash, therefore you will never get switches and arguments mixed up.

However, DOS doesn't have a real glob as far as I know (or at least, it's handled by each app itself, rather than the shell).


You have the DOS/Windows situation backwards. MS-DOS 1 only had one directory per disk, and it used "/" as a switch character just like CP/M and the DEC operating system it was inspired by. MS-DOS 2 introduced several features from Unix like a hierarchical directory system (per disk), but because "/" was already a special character it allowed "" as an alternate directory separator for use on the command line. (Several versions also allowed the switch character to be changed so that "/" could be used on the command line.)

Some versions of bash protect against wildcard-expansion to options by setting an environment variable to specify arguments that should not be treated as options. glibc's getopt() and getopt_long() honour this, but bash no longer sets it. The only reliable way to protect against this is to add "./" in front of a leading wildcard character.

-- Ben Hutchings

Ben Hutchings

DOS did have support for file globbing, and it wasn't something
you needed to handle yourself. The PSP (program segment prefix)
emulated that of CP/M and the primitives FindFirstFile + FindNextFile
allowed your script to easily iterate over a simple glob of files
if your program was invoked with:

foo.com *.txt"

-- Steve