For `--file-size`, one should be able to differentiate files and standard input

[vinc17fr]

The --file-size option is useful to immediately get the size of the (possibly preprocessed) file. However, it is also honored with the standard input while one may not want it in this case, because the whole content is not necessarily available (contrary to a file):

{ echo ab ; sleep 3 ; echo cd; } | less --file-size

takes 3 seconds to get ab displayed

So, for use with the LESS environment variable, either --file-size should be ignored with the standard input or there should be a separate option.

[vinc17fr]

Alternatively, contents could be obtained by less asynchronously (with non-blocking reads), while less is waiting for user interaction. And the size could be displayed once it is known. But this would be more complex to implement.

[gwsw]

Well, there are several possibilities:

1. Reading directly from a pipe or fifo.
2. Reading from a LESSOPEN script.
3. Reading from a file.

Any of these can take a long time. Case 3 is the least likely to do so, but if the file is very large, it can take a long time too. If the user is using LESSOPEN, it is probably in their environment, so they're reading from a pipe every time they invoke less. In that case it doesn't seem useful for --file-size to distinguish reading from a pipe vs. file since the latter case never happens. So I think the only meaningful case when distinguishing between pipe and file is when the user isn't using LESSOPEN. Is that the case you're concerned about?

Of course, the user can selectively enable or disable --file-size individually on each invocation of less, depending on whether they think reading to the end will be slow or not for that particular invocation. Or they can enable it within less via the -- command if they haven't used it on the command line. That's how I use it.

EDIT: or they can just type ^X to interrupt the scan if it's taking too long.

[vinc17fr]

Is that the case you're concerned about?

No, I use LESSOPEN (with a pipe, but it processes an already present file), and this is always very fast: most often, this is just charset conversion, file decompression, or a call to pdftotext (which may take a few seconds on huge PDF files, but anyway, in such cases, this is for a search, and I need the whole preprocessed file).

On the opposite, I often use a pipe for commands that may take time and may involve network access (though I also use this to view diffs).

Or they can enable it within less via the -- command if they haven't used it on the command line.

Typing >< is faster in such a case.

EDIT: or they can just type ^X to interrupt the scan if it's taking too long.

But the interrupt is permanent: one cannot see the remaining of the file a bit later.

[gwsw]

But the interrupt is permanent: one cannot see the remaining of the file a bit later.

Can you describe how you're testing this? If I do

( seq 50; sleep 10; seq 100 150; sleep 10; seq 200 250 ) | less --file-size

and interrupt the scan with ^X, I can scroll down and see the entire input.

[vinc17fr]

With your test, I get only the first 50 lines (I'm testing under Debian/unstable).

[vinc17fr]

But there are no issues under Android (Termux).

[vinc17fr]

This is because Debian still has v668, which is rather old. I could check that the bug was fixed in the merge done just after v668. I've reported the bug in the Debian BTS.