The Classic Blunders

As part of his STEAM education I'm teaching my son Bash programming.

I was running through a series of simple exercises I made up off the cuff to demonstrate some basic principles like streams and redirections and pipes, scribbling on the window over the air conditioning unit in our upstairs office with a dry erase marker, chattering happily about appending vs truncation and built-ins vs utilities in the path that spawn subprocesses, and trying to make sure he got a feel for the way multiple small concepts pile up in a typical statement to create a complex result. I wrote this and told him to run it:

echo $((++n))        

We talked about the math operators, how bash only does integer math, how you could write a script to handle arbitrary precision decimals but why, when there's bc and awk and perl?

We ran that a few times, watching the numbers increase, tossing them to files, cat'ing them back...and eventually, not really thinking the way I should have been, I told him to do this:

echo $((++n)) | grep 2        

n was up to 15 at this point, so I knew it wouldn't show anything, but I told him to just execute it again a half-dozen times, and waited smugly for n to reach 20.

He did as I asked, but nothing changed. I frowned and told him to run the original command again - it spat out '16'.

Do you see what's happening? (I assure you, this is a feature, not as bug.)

Breaking It Down

In Bash, as most linux CLI interpreters, a child process generally inherits a copy of the environment of its parent. One of the first exercises I showed him was to set a variable, run a bash subshell and echo the value - then change it, show the change, and exit the subshell. When you echo the variable again, it shows the original value, because the child only changed its copy.

That is exactly what's happening above. In the echo-to-grep pipeline, the echo runs in a subshell (even though it's a shell built-in) so that its stdout can be redirected to the grep. As a child process, it dutifully increments and reports its copy of n, but cannot change the copy in the parent environment, so every time we ran it grep received a 16.

It isn't hard to fix. Increment as a separate statement before you echo to the pipe, or echo to a file and grep from that, or use process substitution ... but it was a teachable moment, one of those classic things that happen in programming where it looks like the machine has simply lost its mind, but it was really a P.I.C.N.I.C. - "Problem In Chair, Not In Computer."