in reply to Re^3: Replace strings in multiple files
in thread Replace strings in multiple files
As long as you're going to be picky about CMD.EXE vs OS, I'll point out that no OS expands wildcards. It's only the shells that do. So, space_monk's original statement was wrong, but I think that this is just nit-picking, which is why I didn't draw attention to it in the first place. I only bring it up to show why your complaints about CMD.EXE are barking up the wrong tree. We know what he meant, and I didn't see any need to draw up the difference.
Further, your workaround is unlikely to be useful on any OS/shell when the shell isn't involved, such as using system LIST. So knowing to use glob (or not) is still relevant.
By the way, looking at the workaround, I see it's entertainingly wrong anyway. $ENV{SHELL} is also set by 4dos/4cmd by JP Software, and I assume their Take Command products as well. However, they are compatible with the CMD shell (and command.com prior) by not expanding wildcards. I used to use their 4OS2 product way back when, I'm sure I still have the registration codes around the house somewhere. And that's how I found out about the SHELL env var in the first place.
So it's probably a good idea to understand how the various shells work and don't work, how to use glob, when to use it, and what it means if you don't use it. It does make it harder to automatically expand or not, but there are still cases where it doesn't matter the shell or OS or Cygwin or anything (input files).
And, by the way, it's pretty rare that you need to escape the wildcards on systems where the shell does expand them. Re-globbing already-expanded filenames will usually not do anything.