The Unix Chainsaw - Gary Bernhardt
Why Hacker News recommends it
Recommended as a brilliant demonstration of how to think in Unix pipelines.
What it is
Gary Bernhardt's Cascadia Ruby Conference 2011 talk on using the Unix shell for practical problem solving. He builds pipelines interactively by iterative refinement, using small tools as levers.
Recommended by 2 HN commenters across 2 different months, 2016 to 2022.
What Hacker News said
Strong rec agumonkey · 2016-04 · on “Programming blogs”
From the same person: - The unix chainsaw, how to use tiny tools[1] as lever upon themselves. No absurd wit as in wat. Simply brilliant. [this video] - Also listed above the wat page, [LINK] : boundaries, a whole new world. More abstract wishful thinking. Still brilliant.
Strong rec pdkl95 · 2019-02 · on “Problem solving with Unix commands”
Gary Bernhardt[1] gave a great talk about practical problem solving with the unix shell: "The Unix Chainsaw"[2]. "Half-assed is OK when you only need half of an ass." In the talk, he gives several demonstrations a key aspect of why unix pipelines are so practically useful: you build them interactively . A complicated 4 line pipeline started as a single command that was gradually refined into something that actually solves a complicated problem. This talk demonstrates the part that isn't included in the the usual tutorials or "cool 1-line command" lists: the cycle of "Try something. Hit up to get the command back. Make one iterative change and try again." [1] You might know him from his other
Cites pdkl95 · 2017-06 · on “Twice as happy customers means half the marketing spend”
I know I've had a few situations where the "play around with the numbers" part happened first. Usually once the actual goal was known the algebra (or similar details) would be obvious... but sometimes the inefficient/toy implementation was good enough. Sometimes half-assed is ok, if it's the the right half of the ass.[1] The wrong half becomes yet another type of technical debt to be refactored "someday". (this is not an excuse to ignore algebra or blindly assume the easiest/most-fun method is correct/useful/sane) [1] [LINK] via [this video]
Cites pdkl95 · 2019-05 · on “Understanding the fork system call in Unix”
As others have already menti9oned, running 'bc' isn't actually that expensive. Comparing it to Bitcoin is ridiculous. Let's investigate the actual cost of that sum: $ cat foo.sh #!/bin/bash a="1.5" b="0.5" sum="$(echo "${a} + ${b}" | bc)" echo "The sum of ${a} and ${b} is ${sum}" $ /usr/bin/strace -q -D -w -c ./foo.sh The sum of 1.5 and 0.5 is 2.0 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 55.53 0.001225 123 10 read 9.75 0.000215 215 1 execve 5.53 0.000122 7 18 mmap 4.03 0.000089 8 11 3 open 3.04 0.000067 7 10 mprotect 2.99 0.000066 5 13 rt_sigprocmask 2.54 0.000056 56 1 clone 2.45 0.000054 5 10 close 2.40 0.000053 5 11
Cites btschaegg · 2022-01 · on “Ask HN: I’m New to Computer Science and Engineering. Any Advice?”
1.) Be curious. Stay curious. Experiment, play with things. Your time during university is likely the best time for this and it will likely get harder later on when you're on the job and there's much more emphasis on finished work than on learning experiences. Also, I'm quite sure that it will be beneficial for you if you familiarize yourself with different ways of thinking (obviously programming languages, environments and paradigms, but that will likely apply to anything non-technical, as well). I gained this perspective from dealing with people who didn't really do that, but also from knowing that I personally also did this way too late (and from the benefits it brought me nonetheless). I