Piping data to less makes the command pause, as shown with the
following test case.
---- lessbuffbug -------------------------------------------------
#!/bin/bash
[[ -c "$1" ]] || { echo "Usage: lessbuffbug <tty>" >&2; exit 1; }
for (( i=0; i<30000; i++ ))
do
  printf "Line.... %6d\n" $i
  ((i%10)) || echo "Line $i" > "$1"
done
------------------------------------------------------------------

To use it, open two terminals and type in the first one:

  ./lessbuffbug <tty> | less

where <tty> is the tty file of the second terminal (given by the
"tty" command), and wait a few seconds. The data displayed in the
second terminal stop at some line from "Line 4160" to "Line 4600",
showing the lessbuffbug command has paused. Typing spaces in less
leads to more data displyed in the other terminal.

According to the documentation, this behavior is incorrect:

    -B or --auto-buffers
        By default, when data is read  from  a  pipe,  buffers  are
        allocated  automatically  as  needed.  If a large amount of
        data is read from the pipe, this can cause a  large  amount
        of  memory  to  be  allocated.  The -B option disables this
        automatic allocation of buffers for pipes, so that only 64K
        (or the amount of space specified by the -b option) is used
        for the pipe.  Warning: use of -B can result  in  erroneous
        display,  since  only  the most recently viewed part of the
        file is kept in memory; any earlier data is lost.

I don't use the -B option, so I should be in the default case, where
"buffers are allocated automatically as needed".

This is particularly annoying with commands that need a lot of time
to complete.

Package: less
Version: 394-1
Severity: normal

Piping data to less makes the command pause, as shown with the
following test case.
---- lessbuffbug -------------------------------------------------
#!/bin/bash
[[ -c "$1" ]] || { echo "Usage: lessbuffbug <tty>" >&2; exit 1; }
for (( i=0; i<30000; i++ ))
do
  printf "Line.... %6d\n" $i
  ((i%10)) || echo "Line $i" > "$1"
done
------------------------------------------------------------------

To use it, open two terminals and type in the first one:

  ./lessbuffbug <tty> | less

where <tty> is the tty file of the second terminal (given by the
"tty" command), and wait a few seconds. The data displayed in the
second terminal stop at some line from "Line 4160" to "Line 4600",
showing the lessbuffbug command has paused. Typing spaces in less
leads to more data displyed in the other terminal.

According to the documentation, this behavior is incorrect:

    -B or --auto-buffers
        By default, when data is read  from  a  pipe,  buffers  are
        allocated  automatically  as  needed.  If a large amount of
        data is read from the pipe, this can cause a  large  amount
        of  memory  to  be  allocated.  The -B option disables this
        automatic allocation of buffers for pipes, so that only 64K
        (or the amount of space specified by the -b option) is used
        for the pipe.  Warning: use of -B can result  in  erroneous
        display,  since  only  the most recently viewed part of the
        file is kept in memory; any earlier data is lost.

I don't use the -B option, so I should be in the default case, where
"buffers are allocated automatically as needed".

This is particularly annoying with commands that need a lot of time
to complete.

Hi Vincent,
Thanks for your report.  However, I'm not sure I understand the problem.
 The behavior you describe sounds correct to me.  What's happening is
your lessbufbug program is writing data to less and to the second tty in
an interleaved fashion.  Less reads enough data from stdin to fill the
screen (or somewhat more, depending on the relationship between the
buffer size and the screen size).  At that point, less stops reading
stdin because it's waiting for a command from the user.  The lessbufbug
program keeps writing to its stdout, but eventually the system's piple
limit is reached and it pauses, waiting for less to start reading stdin
again.  When the user tells less to display the next page, less then
starts reading from stdin again, which allows lessbufbug to start
writing more data to the pipe.  Surely you wouldn't want less to read
the entire input file before displaying the first page of data.  The
default mode of the -B option simply means that less will allocate new
memory buffers to hold the input data when it needs them -- but it needs
them only when it's necessary to read stdin data in order to fulfill a
request to display data on the screen.  Perhaps you could explain in a
little more detail what behavior you are expecting.

Hi Mark,

OK, I now understand. The man page was quite unclear when saying
"as needed". I thought that this meant "when the buffer got full"
(instead of "to be able to display the current page"). I think it
should be made clearer.

I think that a better behavior would be to wait for a command with
a non-blocking call, and increase the buffer when it becomes full.
A user who wants to limit the buffer size can then use the -B option
(and possibly the -b option too). When reading the description of
this -B option, it seems to really mean this behavior. A new option
could be added too...

Hello,

Good morning,

We have gone through your samples from a partner and Here is our  Order
List. Please do bear in mind that we are very much in  need of this
order, quote your competitive prices.

Kindly send the Order confirmation.

Your early reply will be much appreciated.

Best Regards,

Maryanah Erwin.

PT FINDORA INTERNUSA

Jln Pahlawan 66 Kec. Arjawinangun

45162 CIREBON West-Java INDONESIA

tel : +62 231 357334

fax: +62 231 357260

email: marketing@findora.com