Moreover, there are times when you'll want to do this stuff from within another program. What are you going to do, shell out to a find(1) pipeline? Then people like me will be giving you shit.
There's nothing wrong with rewriting sed in Javascript.
Indeed, especially since there's sed and sed.
The examples given use -i, but no luck with BSD sed, where you will use -i~ at best. Also, lack of -e before the expression may make things blow up at times. And the sed regex does not support stuff like +, so many times I end up replacing sed -i~ -e with perl -pi -e or ruby. Besides, sometimes your looping logic is not implementable with a find easily or at all, especially when its context is readily available in the original language, so maybe you use the CLI at times, but this CLI might just be a frontend to a lib part saving you from forking a thousand times over.
Are you talking about BSD sed here, because GNU sed does support + with the -r flag.
Moreover, if you want to use this as part of your node app, then it's a good reason to reimplement some of sed's functionality.
I still don't see why you'd laugh or ridicule someone else for doing something like this, and sharing it (if anything at all, it serves as a good tutorial on file manipulation with javascript/node IO.
Often not possible depending on what authorizations and hosting you have.
And although its getting a bit off-topic at this point, doing replacements directly in the file isn't even a good idea. The standard "move $file to $file.backup, run sed against $file.backup and pipe it into $file" method is not just recommended because it is portable, it also saves your ass when you messed up your search+replace and broke all your files.
You'd be surprised what is restricted in a lot of corps beyond the "approved" software list. It is amazing what big things get approved and what little things don't.
Here's what print0 does - it separates the filenames with a null byte so that names containing spaces and newlines can be interpreted correctly.
Hopefully someone else will find it useful.
On the bright side, normalizing file names before batch-processing them was a good idea too.
Seriously? find/xargs is nearly impossible to use (safely) without it.
So you know who you're dealing with here, I used Emacs for something like 10 years before I figured out how to do regexp search/replace.
I'm pretty comfortable with my abilities as a software developer. If I was Steve, I'd be about as embarrassed about the idea that someone's "level of understanding" of find|sed|xargs was worth commenting about as I would about the rudeness. Of course, if I was Steve, I'd have apologized privately and not fed into the shitstorm, too. :)
I also think that binary sized string should be the default for shells and command pipelines; plain text was great in the 60s, but it's now the 21st century and I use too many shell flavours on too many systems to remember their arcane quoting rules, locale rules, unicode bugs, etc.
Regardless, it's a shame that there's not a standard separation of UI from functionality in all these utilities - more than once I've wanted to just be able to dynamically link libsort.so from another program because writing files and exec'ing ... urgh.
But it's not. It's a command-line tool. To replace the best, most powerful, most flexible, most stable tool (and additional tools) made for the command-line for this exact purpose. This is the definition of reinventing a square wheel. It's just a bad idea.
(p.s. by using xargs (with or without -print0) you can use one option to parallelize the function, vs writing it all in your own code. but i guess getting mad over a fork/exec call is a better idea)
If you can replace a long line of pipes with a simple command line, then why not?
When admins use it, they often simply shell out to the identical console tools. Why? It's easier. They just do everything you need, they're universal, and they work well together.
Go ahead and write a new Perl in JS, and nothing will change; the console tools will still be there, better than anything else.
I agree that it simplifies the workload. Unfortunately, it does not reduce the workload.
So if the program has overhead when loading, using a -r option instead an outer find loop can make a magnitude of difference to program operation.
by the way: "-print0 | xars -0" is really idiomatic, you know? Lucky you didn't have a single filename with spaces to handle...
It's the shell, by the way, that cares about "spaces in filenames". Not dicking around with shell metacharacters is just one of the many wins you get by not shelling out to accomplish basic programming tasks.
Note that 'xargs -P' behaves very similar to 'make -j' and is often useful as a simple work-unit scheduler.
Still, someone probably rewrote something similar to sed in JS