If I have to read the manual, if it isn't blindingly obvious how to use, I'd rather just use journal or tail -f.
Also a nitpick but the colors are quite garish, perhaps 256 colors and muted or monochrome effects if possible. For some reason the colors on the site screenshot are less saturated than the one packaged in my distro, fedora, 0.12.4.
Can you elaborate a little more? lnav behaves like a pager with the conventional hotkeys for basic stuff. I'm not sure what else you are expecting.
> Also a nitpick but the colors are quite garish
I enjoy colors, so there's a lot going on by default. There are several themes builtin. You can configure the "grayscale" theme by running:
:config /ui/theme grayscale> but there is no obvious way to exit. I tried Q,q
It's not very responsive during initial indexing, which is something I need to improve. Pressing `q` should work to exit in general, though. Pressing CTRL-C three times in quick succession will force quit it.
It would help to know which version you tried. Things have gotten better over the years.
> I tried `man lnav` in separate terminal - but no man page is provided.
A man page exists, but only contains basic information. The builtin help text is much more extensive and can be viewed by running:
lnav -H
> `ps` shows 3 processes which would not die with SIGTERM, have to `kill -9`.
Older versions of lnav would use readline for the prompt and had to run it in a separate process because of "reasons". More recent versions have a custom prompt and don't require the extra processes.
This one, on the other hand, is cleaner and lets you find what you're looking for quickly. And, last but not least, is much lighter.
Really appreciate this way to demo it quickly, very nice!
I've been using klogg and if you're more into GUI's then I think it's the best there is. It opens and searches in log files of many gigabytes with easy. It's a simple and clean multiplatform QT app.
This resonates with my use of grep+less: https://github.com/tstack/lnav?tab=readme-ov-file#why-not-ju...
The only breaking thing was a huge (almost bloated) memory consumption. At that time lnav basically just kept everything in memory. Does anyone did that change?
At some point you need to keep quite a large context in memory to have both decent performance and useful features (that aren't unbearably slow to use). lnav seems to land at a reasonable middle ground.
lnav has never really kept the contents of files in memory. It does build an index of every line in a file. One exception is that it will decompress small gzip files and keep them in memory as a tradeoff from decompressing on the fly.
The memory consumption has never been a problem for me. So, it's not something I've ever focused on.
A new project called logana[2] is written in Rust and is headed in a good direction. Use/contribute to that if you're really interested.
[1] - https://github.com/tstack/lnav/tree/master/src/third-party/l...
Browsers are in C++, do you not use them? Curl is in C, do you not use it? Kernel is C...
curl is heavily fuzzed and you still mostly control what you are downloading unless the target is compromised.
With logs the attacker controls what goes into your logs.
And you don't need to really look very hard, there are a fair number of very recent stack and heap overflows: https://github.com/tstack/lnav/issues?q=is%3Aissue%20heap%20...
First commit is from Sep 13, 2009: https://github.com/tstack/lnav/commit/b4ec432515e95e86ec9d71... . Woah! we’re old.
This is what the UX looked like back in the day: https://github.com/tstack/lnav/commit/bce2caa654160518ec11f6...
I'll also add I used lnav more recently for viewing logs from many small lab devices centralized via syslog, it was extremely lightweight and effective.