tail -f log.txt | less instead . On my quick testing, it updates to advance to the new information, and you can then go up or down. I.e., less updates as an output buffer, not statically referring to the original content.
Or, a slight variation with fewer moving parts (no pipe) -- the solution that Dolphin mentioned in a comment --
less +F log.txt is a nice way to go. Here's what the man page says for
F Scroll forward, and keep trying to read when the end of file is reached.
Normally this command would be used when already at the end of the file.
It is a way to monitor the tail of a file which is growing while it is
being viewed. (The behavior is similar to the "tail -f" command.)
In other words, this is perfect for this case.
It does have one problem that prevents it from being my favorite. An addition like
less +F daemon.log | egrep session doesn't work.
One reason I continue to use pipes in my own day-to-day command line work is that, when coupled with history, it's crazy easy to go back, add a pipe, and change the behavior of your command as the data dictates. If a simple
tail -f log isn't working because of the volume of data scrolling off the screen, slap on the pipe to less. If the volume is too heavy, but you see hints of the lines you're looking for, add a pipe to grep or egrep. Then chain awk, or sed, or cut, to get exactly what you want.
This is also a reason that "unnecessary use of cat" is often a ridiculous criticism. If you cat a file, but find that it is unexpectedly long, use the shell history, hit up-arrow and do something else with it. Quick fix? Just add
cat foo | more. How long is it? Up-arrow and
| wc. How many lines are there with "pangloss"? Add
| egrep pangloss | wc . It's nice if you can start a command knowing exactly where your investigation is going to go, but if you can't, history and pipes are a good way to get things done. Even if it's ugly,
cat file | more | egrep something works fine.