Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
> Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
> which is why the ioctl should take precedence over it.

Readline changes the value of COLUMNS on the fly.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane wrote:
> Aidan Van Dyk <aidan@highrise.ca> writes:
> > 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.
>
> Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
> which is why the ioctl should take precedence over it.

True, but Peter wanted COLUMNS to be honored over ioctl():

http://archives.postgresql.org/pgsql...4/msg01853.php

> > Correctly documenting it is good, just as the version of GNU ls I have
> > on Debian, where I see:
> > `-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.
>
> Fedora 8 has the same wording in "info ls". Possibly Bruce was reading
> the man page, which is not as complete (and admits it).

Oh, you are looking at info. That makes sense now.

> Experimentation on OS X (BSD clone) shows that its "ls" believes COLUMNS
> in preference to ioctl, so there's clearly scope for argument; but on
> the whole I think we should follow the GNU behavior. The BSD version's
> behavior is full of enormous amounts of historical cruft (and its man
> page admits that) --- I suspect the behavior on this point "just grew"
> instead of being carefully thought about.

Well, the GNU 'ls' behavior, because it does not check for isatty(),
will use COLUMNS mostly for file/pipe output because those are the cases
where ioctl() fails. Is that what you want?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bruce Momjian <bruce@momjian.us> writes:
> I just looked at coreutils-6.9 and 5.97 and neither manual has a mention
> of COLUMNS. Seems this is some Debian manual addition or something. I
> don't see it on Ubuntu 7.10 either.

You're looking in the wrong place. See "info ls".

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut wrote:
> Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
> > Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
> > which is why the ioctl should take precedence over it.
>
> Readline changes the value of COLUMNS on the fly.

Yes, but my patch grabs COLUMNS before we call readline(), so we use the
COLUMN value we were invoked with, rather than tracking the changes
readline() makes to it.

If we use COLUMNS as set by readline, there is no way to pass a COLUMNS
value into psql reliably.

'ls' doesn't use readline so it is safe from changes while it is doing
its output.

I can pull COLUMNS as modified by readline() but I thought no one wanted
that.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut <peter_e@gmx.net> writes:
> Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
>> Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
>> which is why the ioctl should take precedence over it.

> Readline changes the value of COLUMNS on the fly.

.... from the ioctl's results, presumably, so what you are saying is that
if readline is active then this discussion is all moot.

In any case I'd be happier if our behavior on this point was not
dependent on whether readline is built in. A normal person would expect
readline to affect only input behavior, not output behavior.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Bruce Momjian <bruce@momjian.us> [080506 11:59]:

> > 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.
>
> The only thing we could do there perhaps is to have psql wrap file
> output to the terminal width if outputting to a pipe/file, but only from
> an interactive session, but that is just too odd. If we make psql too
> automatic it will be hard to explain and have more surprises.

Yes, and *this* is the tough part. And *I* think that the control of
wrapping/width should be based on psql's output fd/$COLUMNS, not
necessarily the query output buffer fd, because I want the interactive
output to be identical when I run the query and let psql automatically
pipe it through $PAGER and when I run the query and tell psql \o it to
pipe it somewhere specific.

Of course, all over-ridden by some specific \pset to make it all more
complicated ;-)

> I just looked at coreutils-6.9 and 5.97 and neither manual has a mention
> of COLUMNS. Seems this is some Debian manual addition or something. I
> don't see it on Ubuntu 7.10 either.

Yes, the man pages point to the Texinfo manual for full documentation:
http://www.gnu.org/software/coreutil...put-formatting

a.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFIII0muVxNPsxNPScRAmM2AKCYawa9b2S74oO03tbw4F fVAlwWIwCff23Z
0wSKFjun382tCPNQnwSGnuI=
=OjXd
-----END PGP SIGNATURE-----

Bruce Momjian wrote:
> Updated patch with clearer documentation that matches the above
> behavior:
>
> ftp://momjian.us/pub/postgresql/mypatches/wrap

I found a bug in my patch, particularly related to wrapping to pipes.
Turns out if psql uses the pager internally:

\pset format wrapped

SELECT 1, 2, repeat('a', 80), repeat('b', 80), E'a\nb\nc\nd', 1
FROM generate_series(1,50);

it does not wrap to the screen width because of our default behavior of
not wrapping pipe output by default. I had to add an is_pager boolean
parameter to print_aligned_text(). (I tried passing is_pager via
printTableOpt but it is a const.)

I have updated the ftp URL to fix this.

One item not addressed is that the 'wrapped' format wrapping could force
output off the page without the pager being used if it is _near_ a full
screen before wrapping. Of course we don't consider additional lines
that wrap by extending past the right margin for non-wrapped mode, so
perhaps it is OK.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Patch applied (yea!).

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Updated patch with clearer documentation that matches the above
> > behavior:
> >
> > ftp://momjian.us/pub/postgresql/mypatches/wrap
>
> I found a bug in my patch, particularly related to wrapping to pipes.
> Turns out if psql uses the pager internally:
>
> \pset format wrapped
>
> SELECT 1, 2, repeat('a', 80), repeat('b', 80), E'a\nb\nc\nd', 1
> FROM generate_series(1,50);
>
> it does not wrap to the screen width because of our default behavior of
> not wrapping pipe output by default. I had to add an is_pager boolean
> parameter to print_aligned_text(). (I tried passing is_pager via
> printTableOpt but it is a const.)
>
> I have updated the ftp URL to fix this.
>
> One item not addressed is that the 'wrapped' format wrapping could force
> output off the page without the pager being used if it is _near_ a full
> screen before wrapping. Of course we don't consider additional lines
> that wrap by extending past the right margin for non-wrapped mode, so
> perhaps it is OK.
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers