Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a CLI app that produces lots of debug output and I have a really big need to search in the output. I'm using less for that but it freezes when I reach the last line with j or G. And it returns back to live only after Ctrl+c, but that way I kill my app.

The problem can be easily reproduced when paging output from find, just use G right after running it.

find / | less

Is it a bug in less?

share|improve this question

2 Answers 2

up vote 0 down vote accepted

Less reads its input lazily. When you start it, it only loads the beginning of the input (enough to fill one screen). As you scroll down, Less loads more and more. If you tell Less to move to the end of the input, it loads everything. If the input is a regular file, Less simply seeks to the end, but when the input is a pipe, there's no way to get to the end of the data other than reading everything.

When a program is piping input into Less, a command such as G to move to the end of the file only returns when the program exits, which can take forever if the program never exits. A command that requires displaying one more line may need to wait for the program to produce that line.

If you press ^C while Less is reading input, Less kills the program, which has the side effect of making it stop producing input. You get to browse through all the input the program has produced.

You can isolate Less from the program to some extent by making the program write to a named pipe. Note that when the program tries to write to the pipe, it will be blocked until Less reads it (just like with a pipeline), and if you exit Less, the program will receive a SIGPIPE signal.

mkfifo f
myprogram >f &
less f

When the input is a named pipe, ^C while Less is reading only makes Less pause its reading, it doesn't have an effect on the program.

You can put Less in “follow mode” (like tail -f), with the F command, to jump to the end and make subsequent input scroll. That's what happens when you try to scroll past the end of the input available so far; the F command additionally makes Less forget that it's ever closed the input file. The command less +F executes the command F when Less starts, i.e. it starts Less in follow mode.

If you want to be able to browse through the debugging output at your leasure and not affect the program, write the debugging output to a file, and call Less on this file. Moving to the end of the file gets you the output so far, but you can resume reading with the F command, interrupt with ^C, and read more with F as many times as you like.

share|improve this answer

This effect is mentioned in man page of less

G or > or ESC->
          Go to line N in the file, default the end of the  file.   (Warn‐
          ing:  this may be slow if N is large, or if N is not specified
          and standard input, rather than a file, is being read.)
share|improve this answer
    
Is there a workaround? –  svlasov Dec 10 '13 at 14:56
    
If you can use less after command completes that is before you use less interactively, invoke less as less +G and it will read to the end of the input, you can then return to the start by typing 1G into less. –  harish.venkat Dec 10 '13 at 15:11
    
try this: Using +F will put less in follow mode. This works similar to 'tail -f'. To stop scrolling, use the interrupt. Then you'll get the normal benefits of less (scroll, etc.). Pressing SHIFT-F will resume the 'tailling'. –  harish.venkat Dec 10 '13 at 15:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.