On Mon, Aug 15, 2016 at 11:25:40PM +0100, Manuel A. Fernandez Montecelo wrote: > The reasoning for the change was that with pipes/redirections the > concept of "terminal" and consequently "width" is lost. If it's > redirected it's possibly/likely that it's because it's moved and > processed elsewhere (where the new terminal size will likely be > different), or that the further processing doesn't bother with terminal > columns or uses smarter methods like using '|' as field separators.
Counterexamples: any PAGER (more, less, ...), grep, sed, and virtually any
filter can interact with the terminal in a later stage of the pipeline.
In some cases like pagers there is *always* a terminal at the end.
> In other words, trying to columnize the output when the width is unknown
> (pipes or redirections) is a bit hacky and doesn't make much sense to
> me, and forcing it to be 80 for a lack of better default is not always a
> good solution as it might have been back in ~2000 (I think).
I agree that forcing to be 80 is hacky. But there is a better solution:
if the output isn't to a terminal (and -w is not passed), write the
entire output without truncating to any width size and let the next
process in the pipeline deal with it. If it's the last process before
going to terminal, I'm sure that program will have code to properly
adapt its output to the actual terminal size. In one sentence: delegate
the job to the process dealing with the terminal.
--
Saludos de Javier <jcant...@escomposlinux.org>
signature.asc
Description: PGP signature
