Rich Gibbs

Session 16: a pipe carries stdout, not stderr

homelab · bash · shell · linux · stderr · pipes · notes

Session 16 (2026-08-23) was the start of a deliberate bash-scripting practice track, not a build session. The real lesson: a pipe carries stdout only, so stderr printed straight to the terminal and bypassed the pipe entirely, which is why piping find output into grep did not hide the permission-denied lines; 2>/dev/null sends stream 2 to a discard target instead. A find invocation also failed until every option had its own leading dash. A recursive, line-numbered content search was started and its result never confirmed, and because the note kept a placeholder instead of the search term, it cannot be re-run from the file alone.

Session 16 was dated 2026-08-23, and it was a teaching session rather than a build session: the first deliberate step into a bash-scripting practice track. Nothing in the lab changed except a cosmetic .bashrc edit on one lab node. Most of what follows is here because I got something wrong, and I want the correction waiting for me next time instead of relearned.

A script needs two things

A shebang line at the top naming the interpreter, and the execute bit. Without the bit the file can be read but not run. Two smaller things from the same example are worth keeping: the environment variable I printed is already set by the shell, so nothing had to define it, and command substitution runs a command and drops its output inline. Running a script from the current directory needs a leading ./, because the current directory is normally not on $PATH.

find: every option needs its own leading dash

My first attempt dropped the dash in front of one option. It did not fail cleanly — it failed confusingly, which is the worse kind of wrong. The rule to keep: every option gets its own leading dash. Once the dash was back, the invocation did what I wanted.

The real lesson: the pipe only carries stdout

I piped find output into grep expecting the flood of permission-denied lines to disappear. It didn't. The reason is the thing I actually want to remember: every command has two output streams — stream 1, stdout, for normal results, and stream 2, stderr, for errors. A pipe carries stdout to the next command. stderr printed straight to the terminal regardless, going around the pipe entirely, which is why grep never saw those lines and could not have filtered them. It wasn't a bug in the receiving command.

The fix sends stream 2 to the null device — a discard target, so anything written there is simply gone. Two related patterns I wrote down while I was there: hiding stdout instead, noted as rarely useful, and the combined form that hides both streams when only success or failure matters. Order matters in that combined form, because the stderr redirection means "send stderr wherever stdout is currently pointing", so that target has to be set first. Get the order backwards and the streams go somewhere other than intended, quietly.

The loose end

The last thing I started was a recursive content search — line numbers, recursion through subdirectories, and the same stderr suppression as before, now applied to a different command. That reuse is the point of writing it down: suppressing stderr is a general shell behaviour, not a trick specific to one command.

I never confirmed the result. It's the open item carried forward to next time.

What bothers me is that the note can't help me pick it up. Looking at what I actually recorded, the command has a placeholder sitting where the search term belongs, and another where the directory belongs — so this tells me I searched for something, and nothing about what or where. The habit worth taking from that: when I start a search I can't finish in the same session, write down the term and the target, not just that I searched.