Re: Proposed patch - psql wraps at window width

* Bruce Momjian <bruce(at)momjian(dot)us> [080506 10:56]:

> What logic is there that GNU ls honors COLUMNS only in non-terminal
> output? And the use of COLUMNS isn't even documented in the GNU ls
> manual page. And BSD ls honors COLUMNS only for terminal output when
> the ioctl fails(). It is hard to see that there is some major
> expectation of how COLUMNS should behave that would make our usage
> "surprising".
>
> If the user wants to set the wrap width for all output, they have to use
> \pset columns.
>
> Also, because we run on some platforms that don't have that ioctl(), we
> are using COLUMNS as a way of providing the width only for screen
> output, like iotcl() does.

I have to admit to using the COLUMNS=... <command> trick myself.

I do have COLUMNS exported in my terminal, and often to stuff like:

ls -C | less

and I expect it to wrap at $COLUMNS (my terminal width) in my pager.

And since the GNU coreutils is pretty consistent in this regard, I often
export COLUMNS=<xxx> in scripts for cron jobs, reports, etc, to get
output that formats nicely for emails, etc.

If I ever wanted the psql wrapped format, I guess *I* would hope that
psql would work that way, simply because that's the way the other tools
I use do it. But I can see that if the other tools work differently,
then there is going to have to be some people (maybe everybody) always
double-checking the psql man page to find out again how it formats.

But since I'm not a user wanting the wrapped format, don't cater to my
hypothetical wants.

But one of the interesting things is that psql has an is *interactive*
mode (something the GNU utils don't have to worry about). So *when* you
choose to figure out your columns is important, and really impacts
behaviour too.

For instance, if I was doing a query, I often to it interactively first:
SELECT [...] FROM [....] LIMIT 50;
And when I'm sure I have the right values,expressions, column aliases,
etc, I do:
\o /tmp/output
SELECT [...] FROM [...];
\o
And in this case, I would expect that /tmp/output would have identical
formatting to the LIMITed query I just ran interactively, not matter
what setting I had for format/wrapped/auto/$COLUMNS.

> We are at least correctly documenting our behavior, which is more than
> the two 'ls' versions I saw did. If users want to set something, they
> better consult the documentation to find out how to do it.

Correctly documenting it is good, just as the version of GNU ls I have
on Debian, where I see:

`-1'
`--format=single-column'
List one file per line. This is the default for `ls' when standard
output is not a terminal.

`-C'
`--format=vertical'
List files in columns, sorted vertically. This is the default for
`ls' if standard output is a terminal. It is always the default
for the `dir' program. GNU `ls' uses variable width columns to
display as many files as possible in the fewest lines.

`-w'
`--width=COLS'
Assume the screen is COLS columns wide. The default is taken from
the terminal settings if possible; otherwise the environment
variable `COLUMNS' is used if it is set; otherwise the default is
80.

`--color [=WHEN]'
Specify whether to use color for distinguishing file types. WHEN
may be omitted, or one of:
* none - Do not use color at all. This is the default.
* auto - Only use color if standard output is a terminal.
* always - Always use color.
Specifying `--color' and no WHEN is equivalent to `--color=always'.
Piping a colorized listing through a pager like `more' or `less'
usually produces unreadable results. However, using `more -f'
does seem to work.

That's pretty straight forward, pretty explicit, and matches the
description of what Greg has been saying all along.

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.