Alvaro Herrera <alvherre@commandprompt.com> writes:
> There is no point in doing things in a certain way just because others
> do the same. Are you going to argue that we need to make the server
> crash from time to time because other systems do that too?

> We came up with dollar quoting which is a completely novel idea AFAIK.
> Why can't we come up with other useful, novel designs?

I don't think there's a need to invent a totally new way of dealing with
window wrapping. If we did, it'd be highly unlikely to preserve the
principle of least surprise.

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

>>> On Fri, Apr 25, 2008 at 3:14 PM, in message
<37ed240d0804251314y72461b8fy8d56606f362f91c6@mail .gmail.com>, "Brendan
Jurd"
<direvus@gmail.com> wrote:

> If the user hasn't specified any format at all, then it's fine to
play
> guessing games and try to select the best format automatically for
> him, based on factors like the destination. But IMO once the user
> makes a determination about the output format, that's the end of the
> story. You toe that line.

I would go further, and say that it would be surprising and
troublesome for psql to guess at whether I want wrapping or unaligned
output. A given set of command line switches and a given set of
inputs should give a consistent output format, regardless of whether
it's going into a pipe or a disk file or out to the local console or
back through ssh. Like a previous poster, I often use an interactive
session to refine something that will be run against a list of servers
with xargs or will be run from crontab. If the interactive output is
big enough to cause it to go through "less", then I still want to see
the format it would have if it didn't. If I save to a file from
"less" or copy and paste from a ssh window when it was a few long
lines, I want it to match what I will get if I run directly to disk.

I consider current behavior pretty darned friendly to the way I work.
Some of the suggestions in this thread sound downright nightmarish to
me. I hope that wrapping never happens without an explicit command
line option or a backslash command.

-Kevin



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

Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > Obviously you have expections of how wrapping should behave. Please
> > name me an application that has a wrapped mode that has the output to a
> > file wrap based on the screen width? It isn't 'ls -C'.
>
> Why would we need to imitate what other apps do? What we need to
> investigate is use cases, and how do we cater for each one, making it
> easy for the most common while at the same time making it not impossible
> for the most obscure.
>
> There is no point in doing things in a certain way just because others
> do the same. Are you going to argue that we need to make the server
> crash from time to time because other systems do that too?
>
> We came up with dollar quoting which is a completely novel idea AFAIK.
> Why can't we come up with other useful, novel designs?

Your argument about crashing above seems like reductio ad absurdum
(http://en.wikipedia.org/wiki/Proof_by_contradiction).

My point was that the poster was saying he expected the file/pipe output
to honor the screen width on output, so I asked him for an example of
why he had that expectation --- that seems logical. Perhaps it is only
to be consistent with other psql behavior.

FYI, ls -C actually wraps to 72(?) unless you specify another width, so
one possible behavior would be for \pset wrapped to wrap to 72 for
file/pipe unless you set \pset columns. That might make the "I want it
always to wrap" group happier, but not the "wrapped shouldn't affect
file/pipe". I have not heard anyone explain why the later behavior is
bad, especially if we default to a width of 72 rather than the screen
width.

--
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

As the originator of the "psql wraps at window width" patch, I'd like to
set a matter or two straight:

The ioctl() function does not fail under ssh, contrary to the assertion
made several times. Nor does $COLUMNS remain static if the window size
changes. $COLUMNS is not a property of a bash, you'll find it is set by
the readline library. $COLUMNS is not fully cross-platform, though
$MANWIDTH should be fine. Please supply counter examples if needed, but
this is pretty well traveled ground. I think the original patch is fat
and happy as far as interactive terminal use.

But I agree it's not desirable to wrap file any sort of stream output,
by default, as that would break just about any script known to mankind.
Yet wrapping is a very user-friendly default for interactive terminals.
This is potentially an irreconcilable inconsistency.

I weigh in on the side of leaving it inconsistent, but making it really
easy to force the behavior you want with something like:
\pset format wrap [auto|nnn|off]

But that leaves a big hole: what does the setting in .psqlrc refer to?
Do we need separate controls in .psql?

\pset format_terminal wrap [auto|nnn|off]
\pset format_terminal html
\pset format_stream wrap [auto|nnn|off]
\pset format_stream html

Where, on a stream, auto and off would have the same meaning, and \pset
format would set both?


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

Am Samstag, 26. April 2008 schrieb Bryce Nesbitt:
> But that leaves a big hole: what does the setting in .psqlrc refer to? *
> Do we need separate controls in .psql?
>
> * *\pset format_terminal wrap [auto|nnn|off]
> * *\pset format_terminal html
> * *\pset format_stream wrap [auto|nnn|off]
> * *\pset format_stream html

I think one of the weirdest behaviors in psql is that it reads the startup
file in noninteractive mode. Unix shells don't do this for good reasons. If
we could work out a change that moves the psql startup file behavior more in
line with that of Unix shells, perhaps meaning separate startup files, then
users could put all the crazy formatting settings they like in .psqlrc
without affecting noninteractive output. And there would still be the
possibility to format noninteractive output the way you want by explicit
intervention. This is basically what your pseudoproposal above would
accomplish, just on a more global scale.

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

Bryce Nesbitt wrote:
> But I agree it's not desirable to wrap file any sort of stream output,
> by default, as that would break just about any script known to mankind.
> Yet wrapping is a very user-friendly default for interactive terminals.
> This is potentially an irreconcilable inconsistency.
>
> I weigh in on the side of leaving it inconsistent, but making it really
> easy to force the behavior you want with something like:
> \pset format wrap [auto|nnn|off]
>
> But that leaves a big hole: what does the setting in .psqlrc refer to?
> Do we need separate controls in .psql?
>
> \pset format_terminal wrap [auto|nnn|off]
> \pset format_terminal html
> \pset format_stream wrap [auto|nnn|off]
> \pset format_stream html
>
> Where, on a stream, auto and off would have the same meaning, and \pset
> format would set both?

Hey, I can work with this idea. First, there really is no 'off' mode
for wrapped because that is aligned. What we could do is to have:

\pset format wrapped display

affect only output to the screen, using the screen width, and:

\pset format wrapped nnn

affect output to the screen and file/pipes.

--
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

[Just when I thought I was out, they pull me back in -- argh, I'm weak]

"Bruce Momjian" <bruce@momjian.us> writes:

> FYI, ls -C actually wraps to 72(?) unless you specify another width,

I told you exactly what ls did, at least GNU ls. It uses -w if specified, if
not then it uses the ioctl if that succeeds, if it fails it uses COLUMNS, and
if that's unavailable it uses a constant.

> one possible behavior would be for \pset wrapped to wrap to 72 for
> file/pipe unless you set \pset columns.

You can't use ls to justify having different rules for screen width for
"file/pipe":

$ COLUMNS=80 ls -C | cat
distmp3.rh3280 gconfd-stark orbit-stark purpleNMN49T ssh-WdHPsk4277

$ COLUMNS=60 ls -C | cat
distmp3.rh3280 orbit-stark ssh-WdHPsk4277
gconfd-stark purpleNMN49T

$ COLUMNS=40 ls -C | cat
distmp3.rh3280 purpleNMN49T
gconfd-stark ssh-WdHPsk4277
orbit-stark

$ COLUMNS=20 ls -C | cat
distmp3.rh3280
gconfd-stark
orbit-stark
purpleNMN49T
ssh-WdHPsk4277


> That might make the "I want it always to wrap" group happier, but not the
> "wrapped shouldn't affect file/pipe". I have not heard anyone explain why
> the later behavior is bad, especially if we default to a width of 72 rather
> than the screen width.

Presumably they're concerned that scripts which dump out data and then try to
parse it will have trouble parsing wrapped output. In any case that should be
based on whether isatty() is true, which is related to but not the same as
whether the window size ioctl succeeds.


--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

--
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 wrote:
> Hey, I can work with this idea. First, there really is no 'off' mode
> for wrapped because that is aligned...
Well, come to think of it, "wrapped" is not really a new output format
in the sense of "html" or "latex". It could build on aligned:

\pset format aligned [autowrap|nowrap|nnn]

But there's still the issue of wanting separate defaults for tty and
stream outputs. The last thing you want is an admin deciding on
wrapping, and then subtly breaking scripts. My personal desired
defaults are:

* Terminals autowrap.
* Streams don't wrap, except in the rare case when I want to force a
specific width (e.g. 79 for a newsgroup posting).

-Bryce



--
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 wrote:
> Hey, I can work with this idea. First, there really is no 'off' mode
> for wrapped because that is aligned. What we could do is to have:
>
> \pset format wrapped display
>
> affect only output to the screen, using the screen width, and:
>
> \pset format wrapped nnn
>
> affect output to the screen and file/pipes.

A new idea would be for a wrap value of zero to be special:

\pset format wrapped 0

to wrap to screen width for terminal and file/pipe output.

--
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 wrote:
> Gregory Stark wrote:
> I don't see that behavior here on Ubuntu 7.10:
>
> $ COLUMNNS=120 ls -C |cat
> archive cd initrd lost+found proc srv usr
> basement.usr dev initrd.img media root sys var
> bin etc laptop mnt rtmp tmp vmlinuz
> boot home lib opt sbin u win
> $ ls --version
> ls (GNU coreutils) 5.97
>
> That is not a 120 width. 'ls' seems to ignore columns for pipe output.

Oops, Alvaro pointed out I typo'ed the variable name COLUMNS as
COLUMNNS. I see now that 'ls -C' does honor columns. See my later
posting about '\pset wrapped 0' as a special case where we could honor
the ioctl/COLUMNS case.

My real confusion is this:

$ echo $COLUMNS
146

$ ls -C|less
archive cd initrd lost+found proc srv usr
basement.usr dev initrd.img media root sys var
bin etc laptop mnt rtmp tmp vmlinuz
boot home lib opt sbin u win

$ COLUMNS=120 ls -C|less
archive bin cd etc initrd laptop lost+found mnt proc rtmp srv tmp usr vmlinuz
basement.usr boot dev home initrd.img lib media opt root sbin sys u var win

Why does the first 'ls' not honor columns while the second does? How
does 'ls' detect that the COLUMNS=120 is somehow different from the
default COLUMNS value?

--
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