Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re^3: Replace strings in multiple files

by afoken (Abbot)
on Nov 13, 2012 at 17:10 UTC ( #1003673=note: print w/replies, xml ) Need Help??

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

The answer to all of the above is glob


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

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.


Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
  • Comment on Re^3: Replace strings in multiple files

Replies are listed 'Best First'.
Re^4: Replace strings in multiple files
by Tanktalus (Canon) on Nov 13, 2012 at 20:33 UTC

    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 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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1003673]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2018-05-21 10:11 GMT
Find Nodes?
    Voting Booth?