How can a Go program tell that os.Stdout is a terminal rather than a pipe or a file?

## Why a program asks A well-behaved command-line tool presents itself differently to a human and to a script. Interactively you want colour, aligned columns, a spinner or a percentage counter, maybe a pager-friendly width. In a pipeline you want none of that: escape codes become garbage in a log file, and a spinner's carriage returns wreck a captured transcript. So the tool asks, at startup, what its output is attached to. ## The standard-library test There is no `IsTerminal` in the standard library. What there is: `os.Stdout` is an `*os.File`, and files can be stat'd. ```go fi, err := os.Stdout.Stat() if err != nil { return err } interactive := fi.Mode()&os.ModeCharDevice != 0 ``` `Stat` returns an `fs.FileInfo`; `Mode()` returns an `fs.FileMode` whose high bits describe the kind of file. The relevant ones: - `os.ModeCharDevice` - a character device. A terminal (`/dev/pts/3`, `/dev/tty`) is one. - `os.ModeDevice` - any device; a character device sets both bits. - `os.ModeNamedPipe` - what you get under `tool | other`. - no type bits at all, and `fi.Mode().IsRegular()` true - `tool > out.txt`. So the three shell situations are distinguishable, and the same test works on `os.Stdin` (is a human typing?) and `os.Stderr` (is the diagnostic stream a terminal?). ## Stat the stream you are writing to This is the mistake worth calling out. Progress and status belong on `os.Stderr`, but the terminal check is habitually written against `os.Stdout`. The two disagree in exactly the cases that matter: `tool > out.txt` has stdout as a regular file while stderr is still the terminal, and the user very much wants to see progress. `tool 2> log` is the reverse. Whichever stream carries the decorated output is the stream to stat. ## What the answer may and may not change Change **presentation**: colour, bold, progress rendering, column padding, whether a table gets box drawing, whether a confirmation prompt is offered at all. Do not change **content**. If the piped form has different fields or a different order than the interactive form, a user who developed a command interactively gets different bytes inside a script, and that is a miserable class of bug to chase. Keep the records identical; vary only the dressing. And expose explicit flags - a `--color=always|never|auto` shape, or an output-format flag - so the detection is only ever the default. ## The limits of ModeCharDevice The check tells you the file is a character device, which is not quite "a terminal a human is watching": - `/dev/null` is a character device. `tool > /dev/null` will look interactive. - Serial ports and other devices are character devices too. - A real terminal may still be unable to render colour, which is why the surrounding conventions matter: a `TERM` environment variable of `dumb`, or a set `NO_COLOR`, should suppress escape codes regardless of the mode bits. - On Windows the notion of a console does not map onto Unix mode bits at all. The rigorous check is a platform-specific terminal ioctl, which is precisely what `golang.org/x/term` wraps. Reaching for it is reasonable in a serious CLI; `ModeCharDevice` is the dependency-free approximation and is good enough for choosing whether to animate a counter. ## Do not ignore the error `Stat` can fail - a closed or otherwise unusual descriptor. Treat a failure as "not interactive", which is the safe default: plain output never corrupts anything, whereas escape codes emitted into a log do. ## What good looks like One small function, called once at startup, returning a struct of presentation decisions: `color bool`, `progress bool`, `width int`. Flags override it. Everything downstream reads the struct rather than re-stat'ing streams in a dozen places, so behaviour is decided in exactly one place and is easy to force in tests.