11–20 of 42 posts
"How to make money by posting a pretty boring article to HN and asking for book purchases at the end of it"
"How to make money by posting a pretty boring article to HN and asking for book purchases at the end of it"
I didn't mind, I actually lolled when reading his other blogpost about how he botched the personal question part of an interview: https://openmonstervision.github.io/blog/posts/how-not-to-ge...
It also doesn't beg for book purchases for books he didn't write... :P
Earlier quoted context omitted.
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 notice…
Dude! 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 pu…
The only time I have to use more complicated constructions is to get around the stupid problem that passing filenames with pipes is almost impossible to do safely.
Earlier quoted context omitted.
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 notice…
I suspect some of this is just a difference in background or culture; shell conditionals look completely obvious and intuitive to me, and I'm pretty sure my team can handle shell better than python.
At 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…
Dude! 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 pu…
I disagree, unless it's slow enough to effect performance, I prefer to combine simple pipes. The only time I have to use more complicated constructions is to get around the stupid problem that passing filenames with pipes is almost impossible to do safely.
At what point it pays off to switch to python/node instead of keep growing a bash script?
Shell with awk/sed/grep is very powerful and very composable for small parsing tasks like this. (It could have been done with even less code than this, but I don't blame the author for not figuring out all the necessary incantations to do so, as these tools can be fiddly if you don't use them every day.)
Earlier quoted context omitted.
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…
There's no reason you can't orchestrate awk and other tools from python though. (I doubt I'm the only one that's done that before).