Re^2: Replace strings in multiple files

[Tanktalus]

in reply to Re: Replace strings in multiple files
in thread Replace strings in multiple files

Why not? Well, a few reasons, I suppose.

First off, not all OS's do filename expansion. CMD.EXE doesn't, for example, at least not last time I tried.

Second, maybe the filename is coming as input from an input file. Putting filenames as a command line parameter isn't always a good option. Maybe it's being run automatically through a web interface without any use of a shell.

Third, maybe the filenames are remote files, files in another directory, or any number of other reasons.

The answer to all of the above is glob (assuming you don't need to recurse subdirs).

[afoken]

The answer to all of the above is glob

No.

Most shells do expand filenames, and for the special case Win32, there is a workaround available (see also Re^3: Perl Rename). This way, the command line interface for a program is consistent across platforms.

If you pass the programs arguments to glob unconditionally, you have to quote the wildcards with every shell that expands filenames, but you must not quote them with shells that don't expand filenames.

First off, not all OS's do filename expansion. CMD.EXE doesn't, for example, at least not last time I tried.

CMD.EXE is not an operating system. It is a shell. Butt ugly, loaded with bug-compatibility back to DOS 1.0, and in desperate need of a clean rewrite, but still a shell, like its slightly uglier father command.com.

Expanding filenames does not depend on the OS. Cygwin offers a bash running on top of Windows, and I would be very surprised if it did not expand filenames. Implementing a tiny and stupid shell that does not expand filenames on Unix is no problem, but people rarely want that. It is a good homework, to understand how a shell works. And it may be useful for a restricted shell.

Alexander

[Tanktalus]

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.