A stderr line is not a result row

The two streams are different files

If you redirect them separately, stdout holds the table or the tally and stderr holds notes about the run: a line the parser could not read, a file it skipped, a clock it could not parse. Mixing the files back together in a ticket makes a warning look like a match.

A terminal shows them interleaved. The note still labels each line with the stream it came from. If you cannot tell, write “stream not recorded.”

A warning does not join the table

“Skipped an undecodable line” means the script did not turn that line into a row. It does not mean the line was a failed login, and it does not add a row to the count. Quote it as a gap in the parse.

Do not delete the warning to make the table look complete. The gap is part of what the run did.

What to write down

File stdout rows as results and stderr lines as run notes. If a person asks how many matches, count stdout. If they ask what was skipped, quote stderr. Do not add those numbers together.

Lab: a warning filed as a third login

Stdout has two CSV data rows for 203.0.113.10 and 198.51.100.20. Stderr says skipped 1 undecodable line in auth.log. A draft adds a third failed login called “undecodable” so the ticket total is three.

The note lists two result rows and one parse gap. The undecodable line was not parsed into an address or a name. It is not a third match. The total of matches stays two.

stdout rows: 2
stderr: skipped 1 undecodable line in auth.log
write: two results, one parse gap
not: three failed logins