Missives from the 6th Floor

In other words, if I have a command prompt open, and I type:

   C:\...> notepad config_*.txt

notepad.exe is responsible for expanding config_*.txt into a list of files to operate on. And in notepad's case, it doesn't. It tries to open a file literally named config_*.txt, and fails.

In POSIX, the shell does that expansion - so if you want to add a nifty feature - say support for regular expressions - you change the shell, and applications are none the wiser. It does mean that shell users

It's a telling example of layering in design and construction - the lower layer (the shell) hides complexity from the higher layer (the application). You could accomplish almost the same technique by putting that code in a shared library, making it easy for application developers to access, but inevitably some developers would forget, or not know, that the library exists. Their applications would be missing that feature or (worse) they'd implement something that's similar, but not identical, to the behavior in the library. (In fact, the shell does use a globbing library, and other applications can use the same library, but they typically don't need to.)

I have no idea why the DOS designers made the decision that applications had to handle wild card expansion. I'm sure they had reasons, and I suspect they had to do with minimizing the resource requirements of the command interpreter. But the decision to make command.com (and later cmd.exe) "dumb" has far reaching consequences.

Oh, those files I needed to open in a simple text editor? I ended up opening a bash prompt (thanks, cygwin), and typing:

   $ for file in config_*.txt; do
   > notepad $file &
   > done