How to Make Money Using Grep, Sed and Awk
openmonstervision.github.io
How to Make Money Using Grep, Sed and Awk
1–10 of 42 posts
Re: How to Make Money Using Grep, Sed and Awk
#2At what point it pays off to switch to python/node instead of keep growing a bash script?
Re: How to Make Money Using Grep, Sed and Awk
#3At what point it pays off to switch to python/node instead of keep growing a bash script?
In my experience it tends to be at around 50 to 100 lines. At this point you usually encounter at least one "gotcha" or difficultly that bash can't handle in an elegant way and realize that it would probably be a lot faster if you just used another language instead.
Re: How to Make Money Using Grep, Sed and Awk
#4At what point it pays off to switch to python/node instead of keep growing a bash script?
Quite a bit after the point where it pays to convert sed and awk one-liners into Perl one-liners and build a program around it.
Perl may be as dead as sed and awk are now, but that was the initial use case for Perl before CGI (as in Common Gateway Interface - the first primitive interface for web apps) came along.
Re: How to Make Money Using Grep, Sed and Awk
#5"How to make money by posting a pretty boring article to HN and asking for book purchases at the end of it"
Re: How to Make Money Using Grep, Sed and Awk
#6At what point it pays off to switch to python/node instead of keep growing a bash script?
[deleted]
Re: How to Make Money Using Grep, Sed and Awk
#7At what point it pays off to switch to python/node instead of keep growing a bash script?
In my experience it tends to be at around 50 to 100 lines. At this point you usually encounter at least one "gotcha" or difficultly that bash can't handle in an elegant way and realize that it would probably be a lot faster if you just used another language instead.
As soon as I start adding ifs and battling to remember the exact syntax I give up and move to Python and argparse. Recently I've started using the Begins[1] library to make useful command line tools and scripts even more quickly. I appreciate it's less and less portable at this stage but so much more productive. Most of the time these scripts are very specific anyway so it's not a concern.
The other thing I've noticed amongst peers is that I'm usually the only one (or one of a limited few) that remotely understand the shell script too. So I'd serve the team better writing it with Python. YMMV with that of course.
Re: How to Make Money Using Grep, Sed and Awk
#8At what point it pays off to switch to python/node instead of keep growing a bash script?
The beauty of bash scripts is that anything with u+x in your PATH, aliases and user-defined functions become a first-class citizen with the same interface. The usual plumbing with pipes and redirection -- and sometimes some more advanced stuff like process substitution -- is often all you need.
Moving to Python, say, makes the control flow and the "software engineering" easier, for sure. However, don't underestimate the power of grep, sed and especially awk. I wouldn't want to reimplement a half-arsed, presumably non-bug-free version of awk in Python when I could have just used awk in the first place.
Re: How to Make Money Using Grep, Sed and Awk
#9Dude! You need help with using your tools' features to reduce your pipeline lengths.
- grep derp | sed whatever is the same as sed '/derp/ whatever' (you might be interested in sed -r for that matter)
- sed whatever | sed whatever\ else is the same as sed -e whatever;whatever\ else
This list is by no means complete but saves a lot of external processes already, and seriously: think about writing the whole thing in pure bash or awk. There might be just too little gain to justify including all these tools without composing the many features they provide.
Re: How to Make Money Using Grep, Sed and Awk
#10At what point it pays off to switch to python/node instead of keep growing a bash script?
At what point should one switch from an interpreted to a compiled language?
There probably aren't any hard and fast answers. Take Dracut [1], for example. It's a successful utility completely written as a collection of bash scripts. The answer probably depends on the specifics of your needs and specific benchmarks.
Bash gets a lot of hate, but if you take the time to really learn it as a language and use good coding practices---like linting, verbose warnings, and unit testing---then it's not too difficult to write long bash scripts well. I don't think it's really much trickier or dirtier than JavaScript.
One thing that helps is putting the spiritual equivalent of "use strict" at the top of your Bash script:
shopt -s -o errexit pipefail nounset noclobber
* Bash Hacker's Wiki [2]
* ShellCheck [3]
* Debugging Bash Scripts [4]
* Shell Scripts Matter [5]
[2] http://wiki.bash-hackers.org/
[3] https://www.shellcheck.net/
[4] http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.htm...