awesome-tuis VS lnav

> Editing multiline inputs is awful.

Outside of "line at a time" i/o (a rarely used mode where an entire line is edited locally and then sent to the host), most of what users see is as interactive is controlled by the program you are interacting with. The terminal just takes commands from the host and does what it is told. BTW, line at a time mode isn't used that much. The only thing I use that uses line at a time mode is telenet in LINEMODE.

> Navigating history is so-so

Yes, that is because the program you are likely interacting with where history is relevant implements it's own repl or command line (i.e. bash, zsh, python, etc...) and it is responsible for it's own history and may implement it completely differently than say, bash or zsh.

> Why are terminals always stuck in the 70s? Can I get a modern terminal?

We do have a modern terminal: the web browser... and it's pretty nice.

There have been a ton of tries at more modern terminals, but ultimately, they end up really being limited by the software running in the terminal session. In the 90s we had a ton of commercial terminal emulators that would allow you to create full guis, complete with dialogs and forms. In the 00's there were a few tries at terminals that would allow html output and embedding of html forms for input (can't remember the names of them). I suppose there's also the whole X11 thing... which is so good enough that it's really hard to kill.

Let's get back to character mode:

A lot of interactive terminal software is built using different libraries - so sometimes you get a terminal gui based on ncurses, terminal.gui, or something else... here's a list: https://github.com/rothgar/awesome-tuis#libraries. Most of these libraries try to use most of the features in your terminal emulator, but often, just use stuff that is in everything.

For command line programs (i.e. just type a command), a lot of the experience is dictated by the parser used by the tool and whatever the underlying operating system has for passing arguments. Some shells and terminal emulators (like iTerm2 on mac) try to smooth this out, but again, there's a lot of variety in command line parsers.

Probably the biggest modern improvement in the shell world was gettext and various command-line completion libraries which allows command parameter completion if the developer supports it or uses a parser that supports completion. But none of this is the terminal itself doing the work.

Haven't done much in grafana but probably use that to constantly output to a small display. Depending on if you want to install a display server... Seems like there are lots of options, maybe grafterm is what you're looking for: https://github.com/rothgar/awesome-tuis

Check out this list of great TUI projects if you really want to see what terminal only is capable of.

This looks really cool! Would you mind PRing it to my awesome TUIs list? https://github.com/rothgar/awesome-tuis

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

Here's a good list

Have a browse at the awesome-tui list and in the reddit search bar: this question is asked quite often and there are already plenty of answers :)

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.

For instance, for terminal input you may want to have a look at https://github.com/rothgar/awesome-tuis, where you will find many terminal user interface libraries (and other examples). I would suggest imtui and fxtui from the libraries section. You may also want to use classic ncurses, as others have suggested.

The code base seems like a good reference as a small Python project.

My fav option in this class of apps: https://lnav.org/ It lets you use journalctl with pipes as requested here: https://github.com/Textualize/toolong/issues/4

For local development, I cannot recommend lnav[1] enough. Discovering this tool was a game changer in my day to day life. Adding comments, filtering in/out, prettify and analyse distribution is hard to live without now.

I don't think a browser tool would fit in my workflow. I need to pipe the output to the tool.

[1] https://lnav.org/

It looks like they run an SSH server inside a Docker container defined by this Dockerfile [1]. This uses the ForceCommand directive in the sshd_config file to ensure that a specific command is run when a user connects (rather than the user connecting directly to a shell).

Depending on whether the user connects as the `playground` or `tutorial1` user they interact with a bash script that is either [2] or [3].

[1]: https://github.com/tstack/lnav/blob/master/demo/Dockerfile

[2]: https://github.com/tstack/lnav/blob/master/docs/tutorials/pl...

[3]: https://github.com/tstack/lnav/blob/master/docs/tutorials/tu...

This is really pretty - I do really wish for a good rust replacement for lnav[1] someday.

1: https://lnav.org/

> I also don't see something else I might want: a way to have a different "view" for certain log messages; maybe to switch between filtering/viewing particular ones, maybe to just have line-format be conditional based on the detected format.

Have a look at the following comment on an issue that might be similar to what you're thinking of:

https://github.com/tstack/lnav/issues/1065#issuecomment-1602...

> I guess I can sort of do this based on `module-field`? but I might want it lighter-weight/finer-grained than that.

Unfortunately, the "module-field" does not work for JSON logs at the moment. It's something I should really fix.

Ultimately, lnav has existed for almost two decades now and I use it every day. So, it's always seeing improvements. If you're having a problem with it, file an issue on github. I don't always get around quickly to fixing other folks feature requests / issues, but it tends to happen eventually.

Thanks.