qq should be on this list. It's like jq but works with multiple file formats, including JSON, YAML, XML, &c. and has a really cool interactive TUI mode.
Modern Linux tools
121–130 of 219 posts
Re: Modern Linux tools
#122I kinda wish there was a modern *suite* of improved tools, developed by one team with consistent designs (parameters, colors, tables, etc.)
Re: Modern Linux tools
#123I'd like to read this list, but the color scheme is among the least accessible that I've ever come across. Dark, greyish-blue text with dark, bluish-grey highlighting over a dark grey background. Wow.
If any fledgling designers are here, then take note and add this to your list of examples to avoid.
Re: Modern Linux tools
#124btop is a worthy and missing contender.
It looks quite fancy but I actually like it more for it's functionality, particularly it's tree view for navigating the processes list. I'm not a big fan of full multicolor in these kinds of tools and so appreciate how easy it is to flip to grey scale mode from the built in colour schemes (even from the TUI settings menu).
Re: Modern Linux tools
#125Earlier quoted context omitted.
That is a differentiator if your competitors are written in Python or Ruby or Bash or whatever. But yeah obviously for marketing to normal people you'd have to say "it's fast and reliable and easy to distribute" because they wouldn't know that these are properties of Go.
You can write slow unmaintainable brittle garbage in any language though. So even if your competition is literally written in Bash or whatever you should still say what your implementation actually does better - and if it's performance, back it up with something that lets me know you have actually measured the impact on real world use cases and are not just assuming "we wrote it in $language therefore it must be fast…
> You can write slow unmaintainable brittle garbage in any language though.
Sure. You can drive really slowly in a sports car. But if you're looking for travel options for a long distance journey are you going to pick the sports car or the bicycle.
Also I have actually yet to find slow unmaintainable brittle garbage written in Go or Rust. I'm sure it's possible but it's vastly less likely.
Re: Modern Linux tools
#126Earlier quoted context omitted.
Thanks yeah this is a good example of why I prefer the simpler interface for `rg` and `fd`. Those examples would actually be fine if this were something only did once in awhile (or in a script). But I search from the command line many times per day when I'm working, so I prefer a more streamlined interface. For the record, I think `git grep` is probably the best builtin solution to the problem I gave, but personally…
>Those examples would actually be fine if this were something only did once in awhile (or in a script). But I search from the command line many times per day when I'm working, so I prefer a more streamlined interface. Makes sense. If I had to do this frequently, I'd add a function/alias encapsulating that `find` incantation to my .bashrc, which I keep in version control along with other configuration files in my home…
Yeah I do the same sometimes, at the risk of going too deep into personal preference. A couple of notes about that approach:
1. I don't recommend using shell functions or aliases for this (e.g., `bashrc`) because then these scripts can't be called from other contexts, e.g., like Vim and Emacs builtin support for shell commands. This can easily be solved by creating scripts that can be called from anywhere (my personal collection of these scripts is here https://github.com/robenkleene/Dotfiles/tree/master/scripts). Personally, I only use Bash functions for things that have to do with Bash's runtime state (e.g., augmenting PATH is a common one).
2. The more important part though, is I don't always want to search in `*.foo`, I want a flexible, well-designed, API that allows me to on-the-fly decide what to search.
#2 is particularly important and drifts in philosophy of tooling, a mistake I used to make is building my workflow today into customizations like scripts. This is a bad idea because then the scripts aren't useful as your tasks change, and hopefully your tasks are growing in complexity over time. I.e., don't choose your tools based on your workflow today, otherwise you're building in limitations. Use powerful tools that will support you no matter what task you're performing, that scale practically infinitely. "The measure of a bookshelf is not what has been read, but what remains to be read."
Re: Modern Linux tools
#127Modern doesn't always mean better. A better replacement for mplayer was mpv, and in some cases mplayer was faster than mpv (think about legacy machines). - bat it's a useless cat. Cat concatenates files. ANSI colour breaks that. - alias ls='ls -Fh' , problem solved. Now you have * for executables, / for directories and so on. - ncdu it's fine, perfect for what it does - iomenu it's much faster than fzf and it almost…
> bat it's a useless cat. Cat concatenates files. ANSI colour breaks that.
From the README:
>Whenever bat detects a non-interactive terminal (i.e. when you pipe into another process or into a file), bat will act as a drop-in replacement for cat and fall back to printing the plain file contents
bat works as normal cat for normal uses of cat and a better cat for all those "useless cat" situations we find ourselves in.
Re: Modern Linux tools
#128These may be objectively superior (I haven't tested), but I have come to realize (like so many others) that if you ever change your OS installation, set up VMs, or SSH anywhere, preferring these is just an uphill battle that never ends. I don't want to have to set these up in every new environment I operate in, or even use a mix of these on my personal computer and the traditional ones elsewhere. Learn the classic to…
Some are so vastly better that it's worth whatever small inconvenience comes with getting them installed. I know the classic tools very well, but I'll prefer fd and ripgrep every time.
For my part, the day I was confused why "grep" couldn't find some files that were obviously there, only to realize that "ripgrep" is ignoring files in the gitignore, that was the day I removed "ripgrep" of my system.
I never asked for such behaviour, and I have no time for pretty "modern" opinions in a base software.
Often, when I read "modern", I read "immature".
I am not ready to replace my stable base utilities for some immature ones having behaviour changes.
The scripts I wrote 5 years ago must work as is.
Re: Modern Linux tools
#129These may be objectively superior (I haven't tested), but I have come to realize (like so many others) that if you ever change your OS installation, set up VMs, or SSH anywhere, preferring these is just an uphill battle that never ends. I don't want to have to set these up in every new environment I operate in, or even use a mix of these on my personal computer and the traditional ones elsewhere. Learn the classic to…
When I got my first Unix account [1] I was in a Gnu emacs culture and used emacs from 1989 to 2005 or so. I made the decision to switch to vi for three reasons: (1) less clash with a culture where I mostly use GUI editors that use ^S for something very different than what emacs does, (2) vim doesn't put in continuation characters that break cut-and-paste, (3) often I would help somebody out with a busted machine where emacs wasn't installed, the package database was corrupted, etc and being able to count on an editor that is already installed to resolve any emergency is helpful.
[1] Not like the time one of my friends "wardialed" every number in my local calling area and posted the list to a BBS and I found that some of them could be logged into with "uucp/uucp" and the like. I think Bell security knew he rang everybody's phone in the area but decided to let billing handle the problem because his parents had measured service.
Re: Modern Linux tools
#130Earlier quoted context omitted.
> bat it's a useless cat I can't see bat as a "useless cat" or a replacement for cat except for reading source code in the terminal. It's more a like a less with syntax highlight or a read-only vim.
Part of the problem is “naming/marketing.” Bat compares ITSELF to cat, not to more/less. IMO, this confuses the issue.
Maybe it should be called "lest"? As in a less/most replacement written in rust. Although it does divert from the theme of more/less/most.