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 <[EMAIL PROTECTED]> 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
