cli-apps VS miller

I personally love TUI software, you don't have to worry about GUI toolkits, mouse focused interaction, you can run them remotely over SSH, they're often composable, and composability is much easier, and who doesn't like the hackerman aesthetic?

Some things I don't like about modern TUIs is developers getting away from the purpose of them, portability. Often you'll find really beautiful TUIs that require installation of custom fonts for icons and other overcomplicated stuff like that. They can be nice, but generally they sacrifice the practical benefit to a significant degree.

One I discovered yesterday, not really a TUI, more of a shell but still, extremely powerful, is kalc https://github.com/bgkillas/kalc which is a complete scientific and graphing calculator in the terminal. It depends on gnuplot which is unfortunate since that is a GUI program, but there we go with composability again! It's fine and works and does what it needs to, so not really a big deal I guess.

To find more:

https://github.com/rothgar/awesome-tuis

https://github.com/toolleeo/cli-apps

See also https://github.com/toolleeo/cli-apps

I already manage this Awesome list on Github, which currently lists 570+ programs.

https://github.com/toolleeo/cli-apps and https://github.com/rothgar/awesome-tuis? Though it doesn't mention a specific GUI apps (eg, Lynx is under either Web Browser or Web on those lists), and it's just lists, no actual comparison or review etc. I usually found AlternativeTo to be somewhat decent start to see what features and alternatives I can expect across platform.

jq and miller[1] are essential parts of my toolbelt, right up there with awk and vim.

[1]: https://github.com/johnkerl/miller

> This works really well if your problem can be solved in one or two liners.

My personal comfort threshold is around the 100-line mark. It's even possible to write maintainable shell scripts up to 500 lines, but it mostly depends on the problem you're trying to solve, and the discipline of the programmer to follow best practices (use sane defaults, ShellCheck, etc.).

> It go bad very quickly when, say, you have two CSV files and want to join them the sql-way.

In that case we're talking about structured data, and, yeah, Perl or Python would be easier to work with. That said, depending on the complexity of the CSV, you can still go a long way with plain Bash with IFS/read(1) or tr(1) to split CSV columns. This wouldn't be very robust, but there are tools that handle CSV specifically[1], which can be composed in a shell script just fine.

So it's always a balancing act of being productive quickly with a shell script, or reaching out for a programming language once the tools aren't a good fit, or maintenance becomes an issue.

[1]: https://miller.readthedocs.io/

where mlr is from https://github.com/johnkerl/miller

if this class of problems (i.e., csv/tsv data) is your main target you may find miller (https://github.com/johnkerl/miller) much more useful in the long run

That said, you may be interested in Miller (https://github.com/johnkerl/miller) which provides similar capabilities for CSV, JSON, and XML files. It doesn't use a SQL grammar, but that's just the proverbial lipstick on the thing. I'm not the author, but I have used it and I see some parallels in use cases at the very least.

worth giving Miller a shot

CSV utilities (still haven't pick a favorite one...): https://github.com/harelba/q https://github.com/BurntSushi/xsv https://github.com/wireservice/csvkit https://github.com/johnkerl/miller