[wellylug] Man-page formatting

Ewen McNeill wellylug at ewen.mcneill.gen.nz
Fri Jul 1 10:00:53 NZST 2005


In message <1120127757.4408.49.camel at localhost>, Grant McLean writes:
>I've definitely confirmed that exactly the symptoms I described occur on
>both woody and sarge.  In fact I tested it before sending my message.
>[...]
>I have noticed that it seems to make a difference whether less is
>reading from a file or a pipe that's blocked.

How very interesting, so it does.  If a simple "less FILE" is running,
then COLUMNS is updated by the next bash prompt.  But if a file is piped
into less, then it isn't.  This is true even if the pipeline isn't
blocked (except by less pausing), such as "cat FILE | less", or even if
the process isn't actually using the pipe, such as "cat /dev/zero | less
FILE".  (In that latter situation less displays the file.)

Playing with strace suggests that in neither scenario does bash receive
a SIGWINCH (it goes to the current running foreground process).

Looking at the bash source there appear to be two functions used to
obtain the current window size, one in jobs.c and one in nojobs.c, both
static functions called get_new_window_size().   They appear to do much
the same thing, but with different assumed ttys.  And they're called
from various locations where bash thinks it needs to update the terminal
width values (including, but by no means exclusively, when SIGWINCH is
received).  (Search for TIOCGWINSZ if you care; that's the ioctl() call
used to retrieve the terminal size.)

So my assumption is that there's a case to do with the handling of
pipelines in which bash either (a) doesn't think it needs to update the
terminal width, or (b) tries to do so based on the wrong tty handle.

>The common scenario I run into is piping something into less, adjusting
>the terminal size and then exiting less to find bash's line-wrapping is
>messed up.

Incidentally this is because the readline terminal width values are not
updated correctly.  That's another thing that bash's
get_new_window_size() function tries to update when it's called.
Manually resetting COLUMNS makes no difference in that case, as it
doesn't seem to get pushed down to readline.

I'd suggest you report it as a bug in bash; the handling of window
resizing when "less FILE" is running compared with when "cat /dev/zero
| less FILE" is running would seem to be a reasonably good test case
(assuming the two are also treated differently in your situation).
(It appears to matter that the start of the pipeline doesn't exit early;
"true | less FILE" doesn't seem affected.)

I still suspect this doesn't have much to do with the man page display
issue, since AFAICT man (at least here) doesn't use the COLUMNS
environment variable, and it happens even first time out with a
not-resized terminal.  A "COLUMNS=50 man man" would double check that.

Ewen




More information about the wellylug mailing list