In the spirit of OnceAndOnlyOnce, I've lately been noticing repetitive tasks and writing shell scripts for them.  One of the things I've caught myself doing many times is doing one-line perl invocations that are what I call "read/write grep"'s -- that is, search and replace with greppish semantics.

''(Download CvsTools for source)''

Notice that it just passes whatever you send it directly into the perl command -- in other words you can use full perl RE's.  Specifically, you might want to use \b's.

Example invocation (if the above is put in a script named "rwgrep"):
 rwgrep '\bcustidreg\b' 'registeredCustomerId' *.java

You will then be asked if you want to keep your changes for every file (even if there are no changes, though I'm going to eventually make it so it only prompts if there were changes).

''Compare:''
 ''perl -i~ -pe 's/\bcustidreg/registeredCustomerId/g' *.java''

What happened to the link? It does not seem to work.

Doh, ever heard of shell aliases?

  alias rwgrep='perl -i~ -pe'

Now you just type

  rwgrep s/this/that/ *.java

''Congratulations, this has just reinvented '''sed''' :-)''
----

See SedLanguage

----
People who do not use vi, or never learned its ex mode, can skip this:

The "ex" mode of vi is an excellent tool for editing files via a static script. That's what editors are for, after all!

Put the ex commands in a script file, remembering to end with :wq to write and quit (otherwise the changes aren't saved on exit, of course), and you can then interactively try out the script with ":source scriptfile" or run it on the command line with "ex - file < scriptfile" (the "-" is the anti-verbose flag).

It supports a few very, very powerful things that would be quite difficult to do as simply with any other tool, even perl, such as mixing line ranges with global and using the ";" separator, moving backwards with ? to find a previous line after each // match, etc.

Even if you're not familiar with those lesser-known features, it still is often more direct to use a simple edit script than to debug a program in another language.

This may not be suitable for production use if one is concerned that maintainers will be incapable of learning (or unwilling to learn) ex commands; to avoid holy wars it's probably better just to use perl, even if its more complicated and error prone for certain tasks.

The counter-argument to that is that holy wars don't start over using sed, yet ex and sed are both standard tools that use similar syntax derived from exactly the same source (ed), so what's the big deal? -- dm

''Yeah, using ex as a replacement for perl OneLiners is a good idea, if you already master the ViFu.''