Around Go: command line · 3 MIN READ

Find code and inspect logs from the command line

Combine find, grep, head, tail, sort and uniq without hiding their exit behavior.

Most development investigations begin with a filename, a symbol or a short log fragment. Use small commands to narrow the evidence before opening a huge file. The examples assume you are in a trusted Go project and have a text application log named app.log.

01

Find source files and search their content

find selects filesystem entries; grep searches text. The quoted pattern *.go is passed to find rather than expanded by Bash. -exec passes each discovered filename as an argument, preserving spaces without parsing the output of ls.

bash
find . -type f -name "*.go"
find . -type f -name "*.go" -exec grep -nH -F "ListenAndServe" {} +
Read the code

The first command lists Go files. The second prints filename, line number and matching text. No matches can produce a nonzero grep status; distinguish that normal search outcome from an unreadable file.

02

Read a bounded part of a log

head shows the beginning, tail the end, and tail -f follows appended data until Ctrl-C. Bound a first inspection instead of loading a multi-gigabyte file. Filtering stdout does not capture stderr from a program unless you redirect it explicitly.

bash
head -n 10 app.log
tail -n 40 app.log
grep -n -F "timeout" app.log
tail -f app.log
Read the code

Stop tail -f with Ctrl-C when you have enough evidence. It does not stop the process writing the log. grep finds the literal timeout string and reports line numbers rather than interpreting it as a regular expression.

03

Count repeated messages with a clear assumption

uniq -c combines adjacent equal lines, so sort first if order does not matter. This simple pipeline counts exact repeated lines; real structured logs often contain a different timestamp per event and need field-aware parsing.

bash
grep -F "ERROR" app.log | sort | uniq -c | sort -nr | head -n 10
Read the code

The result is a frequency list of identical ERROR lines, not an error rate. With pipefail, an early writer can report a broken pipe when head exits; do not reuse a viewing pipeline as an unquestioned CI pass/fail gate.

TAKE THIS WITH YOU

Use find for paths and grep for text; quote patterns and preserve filenames as arguments. Bounded log inspection and explicit pipeline assumptions are more useful than printing every file.

Check your understanding

Why does counting repeated lines usually sort before uniq -c?

Go to the source

Progress stays in this browser. No account needed.