In data science/industry it frequently happens for people to open files bigger then the available memory in less. "Big data" is a somewhat independent concept of the fact that RAM was smaller 30 years ago.
ov looks really nice and probable deserves a try. I like the section thing, it's going to be useful for diffs to go file by file.
One feature I discovered recently in less that I'm always using now is filtering: type '&' and then the thing you're looking for, and less will only show matching lines.
Looks like posting this to Hacker News got it packaged for Nixpkgs¹! I had to add it via package override when the article came out, but it's since been added to Nixpkgs. :)
If you're a NixOS newbie and you don't want to wait for the PR to land, you can add it with a package override by pasting in the function body from the PR and prepending a `with` expression for the original Nixpkgs used in the override, like:
nixpkgs.config.packageOverrides = superPkgs: {
ov = with superPkgs; buildGoModule rec {
pname = "ov";
version = "0.13.0";
<...>
meta = with lib; {
description = "Feature-rich terminal-based text viewer";
homepage = "https://noborus.github.io/ov";
license = licenses.mit;
platforms = platforms.linux ++ platforms.darwin;
};
};
};
Hopefully in a week or two, Nixpkgs will provide another convenient way for Linux and macOS users to quickly try out this new pager! I know I'll be following along to see how it develops. :)
Yeah I experimented with it, seemed to work out of the box. I used `ov -f` so it starts at the end of the scrollback. Searching behaves strangely (different from vim). Seems to run fast but I haven't tried it on giant scrollbacks yet.
- "Just use vim" (and vim's paging is really good, so this is viable, in fact probably the most viable so far)
`less` is a great program, despite being old there aren't really many flaws. It's one of those tools that don't really need updates or improvements. But I do think there are a few features which would be nice to have (automatic ANSI coloring, tailing, syntax highlighting, support for files like sqlite and tar - which of which are in ov).
The one thing which `less` may have over `ov` (besides already being on most distros) is speed. `less` takes in really large files, or forever terminal output, and is still really fast. And I find that when I use `less` I use it with large files or terminal output often. Though I don't actually know if `ov` is any slower, it's something the dev should watch out for (I don't see "speed" mentioned in the README).
ANSI coloring and tailing is supported by less. Press F to start tailing. Many programs detect if they are redirected to a pipe and then stop to emit ANSI color codes.
Nice! I've been in rapid-response situations where I had to pull logs from various sources (including embedded devices) that weren't unified in a central logging service. I could get the logs onto my workstation, but then manually lining up who-saw-what-when involved a headache, even with Emacs. lnav seems to have a few features to support this.
One very useful feature for this I didn't see listed for lnav was to support adjusting for timestamps in different timezones, like maybe you have a desktop's log in local time that you're trying to reconcile with servers. (A related but less-important bonus would be to be able to specify smaller arbitrary clock drift/offsets for each log.)
> One very useful feature for this I didn't see listed for lnav was to support adjusting for timestamps in different timezones, like maybe you have a desktop's log in local time that you're trying to reconcile with servers. (A related but less-important bonus would be to be able to specify smaller arbitrary clock drift/offsets for each log.)
How is it useless bias? Go has not proven itself that it has what it takes to be a language that a developer would want to use. What problems has it solved that no other language has solved? What problems has it solved better than other languages that also solved them?
The answers to those two questions have not impressed me. So, if my bias is simply using basic logic to evaluate a language, then I think I'm going to keep using my "useless bias".
All of the Go projects I've used have been well-constructed and efficient. It's the language the devs chose, and it lends well to the things it's been used for. Personally, I really like the syntax. Those reasons are good enough for me.
I also dislike Go the language, and I tend to write new things in Rust. But that's my choice as a dev. As a consumer of stuff other people have taken their own precious time to write and let me use for free ... No, I have no business telling them their choice of tool is wrong.
I'm not part of the Go cult, so I simply do not get why people would start brand new projects in it when so many other good languages exist that actually seem to have taken off and become popular enough to survive long-term.
There are multiple lengthy writeups on the good and bad of Go that have made it to the HN front page multiple times over the past 5+ years. The little search bar at the bottom HN works pretty well, sometimes better than Google due to HN's habit of promoting interesting and well written blog posts, podcasts, and talks about technical subjects.
On my end I love Go executables because I know they’re fast, self contained with very little dynamic linking or dependencies, and I know I can (and do!) contribute easily.
I try to avoid Python tools because they depend too much on the installed Python version (even with 3+ I’ve had incompatibility issues), are generally slow (I use autojump because it’s best in class IMO compared to zoxide, z, or jump, but it’s slow as a cow), and sometimes suffer from bad error handling (the few Python tools I use like awscli routinely give me Python stack traces whereas Go or Rust tools rarely, if ever, fail that badly)
Now that you have an example, what are your arguments against Go tools?
[0] https://github.com/noborus/ov/issues/201