How do you keep a Go error message on one line when it embeds a filename supplied by a user?

## The invariant being protected A Go error message is one line of text with no trailing newline, because whoever finally prints it decides the formatting. That invariant is entirely under your control for the words you write — and entirely out of your control for the values you interpolate. ## Where the line break comes from Consider a tool that reports which file it could not read: ```go return fmt.Errorf("read %s: %w", name, err) ``` If `name` came from a command-line argument, a config file, an archive entry, or a request, it can legitimately contain almost any byte. On Unix a filename may contain a newline. A header value may contain a tab. A field copied out of a document may contain a carriage return or an ANSI escape sequence. Any of those pasted raw into the message means the rendered error is no longer one line: log ingestion sees two records, a `grep` for your prefix returns a fragment, and a terminal may even act on the escape sequence. ## The fix: %q ```go return fmt.Errorf("read %q: %w", name, err) ``` `%q` formats a string as a double-quoted Go string literal. That gives three properties that matter for error text: 1. **Escaping.** A newline is rendered as the two characters backslash and `n`, a tab likewise, and other control bytes as escapes. The message cannot be split by its own data. 2. **Delimitation.** The quotes mark where the value starts and ends. In `read "": ...` you can see that the name was empty; in `read : ...` you would be left wondering whether the formatting broke. A value that is entirely spaces is visible for the same reason. 3. **Byte safety.** Bytes that are not valid UTF-8 are rendered as hexadecimal escapes rather than being emitted raw into a terminal or a log. This is why so much standard-library error text quotes the offending value rather than pasting it: the message stays well-formed no matter what the input was. ## Runes, not bytes Go strings are immutable bytes that are usually — not always — UTF-8. Two consequences show up here. First, a message is measured by a reader in characters but stored in bytes, so a name of ten characters may be thirty bytes; truncating by slicing bytes can cut a multi-byte rune in half and produce a replacement character in the middle of your message. If you must truncate, truncate by runes, or truncate and then quote. Second, printable non-ASCII text — a filename in Cyrillic or Japanese — is legitimate and `%q` leaves it readable rather than mangling it; the escaping applies to control and invalid bytes. ## Size, not just shape The same instinct applies to length. Interpolating an entire request body, an entire query result, or a multi-megabyte string into an error message produces something no human will read and that will dominate a log bill. Bound what you embed: a prefix of the value plus an indication that it was truncated is more useful than the whole thing, and it keeps the message scannable. ## What quoting does not do Quoting is a *rendering* concern, not a safety boundary. It makes the message well-formed and unambiguous; it does not decide whether that value belonged in a user-visible message in the first place, and it is not a sanitiser for any downstream system. Nor does it excuse a trailing newline: never append `\n` yourself, quoted or not. ## The habit A simple review rule covers nearly all of it: **your own words go in as plain text; anything that came from outside your program goes in quoted.** Applied consistently it makes every message in a codebase parse the same way, keeps the one-line invariant true even for hostile input, and removes a whole class of confusing bug reports where the pasted error was missing half of itself.