I found that when the output is piped it doesn't invoke the pager. This seems reasonable to me.
What doesn't seem reasonable is the truncation behaviour. When the output isn't piped, it gets truncated to the width of my terminal. When the output is piped, it gets truncated to 80 columns. I'd expect no truncation when the output is not a terminal.
This is an outdated systemd though (I installed it on a Rasberry Pi [Raspbian] in order to play with it), so this may have changed.
>By default, less displays the contents of the file to the standard output (one screen at a time). If the file name argument is omitted, it displays the contents from standard input (usually the output of another command through a pipe). If the output is redirected to anything other than a terminal, for example a pipe to another command, less behaves like cat.
That could be, but the change in wrapping behaviour makes me think it's journalctl doing it. If less acts like cat when the output is a pipe, then it wouldn't be wrapping at 80 columns, so journalctl must be doing the wrapping in that scenario.
yum does the same thing. I actually looked at the code and it always assumes the output width is 80 characters and wraps or center…truncates if output isn't a terminal. It also doesn't properly sort its output, so you're tempted to use `yum search | sort`, which ends up with indented lines at the top of the output.
Of course, the recommended thing to do is use a different program for scripts/pipelines rather than yum, so now there are two different interfaces that need to be remembered. yum looks like a terminal-friendly program, but actually isn't.
What doesn't seem reasonable is the truncation behaviour. When the output isn't piped, it gets truncated to the width of my terminal. When the output is piped, it gets truncated to 80 columns. I'd expect no truncation when the output is not a terminal.
This is an outdated systemd though (I installed it on a Rasberry Pi [Raspbian] in order to play with it), so this may have changed.