-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 26, 2008 at 5:08 PM, Bryce Nesbitt
wrote:
> 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]
>

I agree that wrapped is more a variant of aligned mode than a format
mode in its own right. Expressing it that way with \pset has the nice
bonus that you don't lose your preference for wrapped mode when
switching between aligned and unaligned with \a.

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

Well, if we pursue Peter's suggestion that psql abstain from reading
the startup file in noninteractive mode, then this problem goes away.
An admin could opt to wrap in his interactive sessions without it ever
affecting the behaviour of scripts ... which is exactly what you would
want.

Cheers,
BJ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: http://getfiregpg.org

iD8DBQFIEs3x5YBsbHkuyV0RAiPsAJ0QIhWmq4s622dTZNP4Mk nxWTm30wCfaMTP
kY9qEW0GB3rJb3Xq5F92geY=
=GbOb
-----END PGP SIGNATURE-----

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

Gregory Stark wrote:
>
> [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.

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

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.

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

Right now we honor $COLUMNS only when isatty() is true.

--
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> [080426 09:44]:

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

I would hazard a guess that COLUMNS isn't "exported" from your
shell environment in the first case. In the other cases, the explicit:
VAR=... command
the shell is told to set VAR explicitly before starting command, in
addition to any exported vars.

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)

iD8DBQFIEzKQuVxNPsxNPScRAgCZAKCIu1WAqZ9irgEAJxcd5q EwEDLfMwCgmrh+
ET1CbPL2z73mv3xPM3V85Wc=
=n3V1
-----END PGP SIGNATURE-----

Bruce Momjian wrote:
> 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?

Ah, I see now. $COLUMNS isn't exported to subshells, hence the previous
comment that readline needs to be called before it has a value. It
seems psql does have COLUMNS set if readline is defined, which means we
can't detect of $COLUMNS was passed to psql or was detected. More
interesting, it doesn't seem psql sets $COLUMNS in batch mode:

psql -c '\echo `echo $COLUMNS`' test
{blank line}

COLUMNS=120 sql -c '\echo `echo $COLUMNS`' test
120

so we could argue that COLUMNS should be honored but again this would
affect \g filename. The issue with 'ls' is that it knows it isn't going
to be getting new commands from the user that change where its output is
going, while psql can.

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

Well, it's *certainly* gonna ignore "COLUMNNS".

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

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>
>> 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
>>
> Well, it's *certainly* gonna ignore "COLUMNNS".
>
> regards, tom lane
>
I'm having trouble seeing the relevance, either way. First many shells
don't set $COLUMNS at all (readline does it for psql). And most shells
that set $COLUMNS don't export it. So most people get different output
from:

# ls -C
# ls -C | cat

Unless they are in the habit of doing:

# COLUMNS=$COLUMNS ls -C |cat

I think it's too weird to default pipes to whatever the terminal width
happens to be. So that leaves you with an explicit command to set the
width for pipes.

-Bryce


Echo $MANWIDTH


--
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" <bryce2@obviously.com> writes:

> Unless they are in the habit of doing:
>
> # COLUMNS=$COLUMNS ls -C |cat

Some of us are actually in the habit of doing that because it's easier to use
the standard interface than remembering the different command-line option for
each command. I quite often do precisely that with dpkg, for example.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

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

Gregory Stark wrote:
> "Bryce Nesbitt" <bryce2@obviously.com> writes:
>
> > Unless they are in the habit of doing:
> >
> > # COLUMNS=$COLUMNS ls -C |cat
>
> Some of us are actually in the habit of doing that because it's easier to use
> the standard interface than remembering the different command-line option for
> each command. I quite often do precisely that with dpkg, for example.

Yes, this is true, but it assume the application is not going to set
$COLUMNS itself, like psql does in interactive mode:

test=> \echo `echo $COLUMNS`
127

$ sql -c '\echo `echo $COLUMNS`' test
(empty)

Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
but that seems confusing.

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

> Gregory Stark wrote:
>> "Bryce Nesbitt" <bryce2@obviously.com> writes:
>>
>> > Unless they are in the habit of doing:
>> >
>> > # COLUMNS=$COLUMNS ls -C |cat
>>
>> Some of us are actually in the habit of doing that because it's easier to use
>> the standard interface than remembering the different command-line option for
>> each command. I quite often do precisely that with dpkg, for example.
>
> Yes, this is true, but it assume the application is not going to set
> $COLUMNS itself, like psql does in interactive mode:
>
> test=> \echo `echo $COLUMNS`
> 127
>
> $ sql -c '\echo `echo $COLUMNS`' test
> (empty)
>
> Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
> but that seems confusing.

We could always read COLUMNS early on before readline is initialized and stash
the value away in a variable. But...

We would only look at COLUMNS if the ioctl for window size failed. Does
psql/readline do anything to COLUMNS in that case?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

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

Gregory Stark wrote:
> > Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
> > but that seems confusing.
>
> We could always read COLUMNS early on before readline is initialized and stash
> the value away in a variable. But...
>
> We would only look at COLUMNS if the ioctl for window size failed. Does
> psql/readline do anything to COLUMNS in that case?

We do look at COLUMNS if the ioctl() fails, but not for 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