Recently I wanted to audit some Helm charts for trailing whitespace bugs. This stuff can be a real bugbear, so an automated check can save a lot of hair-tearing. I initially reached for the beloved awk, but it turned out that grep could actually do exactly what I wanted.

My awk implementation looked like this:

#!/usr/bin/awk -f
BEGIN {
  e = 0;
}
/[[:space:]]+$/ {
  printf("FAIL: trailing whitespace at %s:%d:", FILENAME, FNR);
  print;
  e=1;
}
END {
  exit e;
}

This works, and it even nicely sets the awk process exit status to 1 (ie. failure) if it found something. Good for test harnesses.

$ find $HOME/vc -name '*.go' | grep -v /vendor/ | xargs checks/trailing-whitespace.awk
FAIL: trailing whitespace at /Users/jsleeio/vc/someproject/somefile.go:74:			resp := `{
FAIL: trailing whitespace at /Users/jsleeio/vc/someproject/somefile.go:75:				"error":{

But… don’t be hasty! Here’s the grep approach:

$ find $HOME/vc -name '*.go' | xargs grep -n '[[:space:]]\+$'
/Users/jsleeio/vc/someproject/somefile.go:74:			resp := `{
/Users/jsleeio/vc/someproject/somefile.go:75:			"error":{

The only real advantage of the awk approach in this application was telling the reader directly what the failure was about. In exchange for this benefit, I had to write the awk script, and then later realise that my line numbers were mostly wrong because I’d used NR (total number of records seen) instead of FNR (number of records seen in the current file).

Less than a minute of browsing the grep online documentation could have avoided this. A valuable lesson.