I'm in the habit of keeping a text file with all software I've installed and updating it immediately. Really helps remember stuff like this.

Also I use dmenu and a script for using aliases in dmenu, and I create aliases for popping them out in new terminals. Really fast workflow.

If you're using a lot of tui stuff changing workflow from double click to launch really makes the whole experience smoother, much smoother than GUI stuff.

dmenu is great for a graphical environment. At the prompt, I've found some success with slmenu [0]. It's a dmenu clone for the command line. It works well enough that a dmenu script for a todo app works with very little changes [1]. As a launcher there's many dmenu example scripts to start from. Youtube has videos to get you started as well [2].

[0] https://github.com/lpsantil/slmenu

[1] https://github.com/lpsantil/slmenu-todo

[2] https://youtu.be/SlJto75auCA

Why not just type the command you're trying to type and tab autocomplete it?

I do that often myself. If you've written the command before, there's also vi mode for bash history, OR, even bash-completion package for some OSes that can give arguments for simpler commands. However, I see a couple minor limitations.

1. You're limited to binaries and executable scripts in your $PATH

2. Many commands do not have bash-completion support.

vi mode for bash, bash-completion are both innovations trying to tackle this optimization of workflow. I see tools like dmenu and slmenu as better ways to give richer UI and create/reuse workflows. GP's request for `allows fuzzy search of program names, tags and a short description` is highly doable in dmenu/slmenu if not already done [0]. Not so much with bash, vi mode for bash, bash-completion.

[0] https://tools.suckless.org/dmenu/scripts/

> GP's request for allows fuzzy search of program names, tags and a short description is highly doable in dmenu/slmenu if not already done

May also use i3-dmenu with fzf:

    urxvt -title "fzf-menu" -e bash -c 'i3-dmenu-desktop --dmenu=fzf'

> I'm in the habit of keeping a text file with all software I've installed and updating it immediately. Really helps remember stuff like this.

Coincidental - I just reinstalled my machine and this is the first site I came to. I keep all the applications I installed in a 'packages.new' file, and do

    apt-get install -y `cat packages.new`

when I get a new machine.

How do you keep track when installing appimages, flatpaks, tarballs, compiling source and things like that?

It's not quite the same, but I keep a similar file that notes: installed packages from the distribution repository, installed packages from AUR, enabled services, and installed extensions from programs where they can be installed from the command line. (Plus I'll note what has been removed, so I don't forgetfully install things that I've had problems with in the past.) Since everything is one item per line with few extraneous notes, it is easy to pull into Vim and modify into a script.

Properly taken notes are much more than a memory aide.

> How do you keep track when installing appimages, flatpaks, tarballs, compiling source and things like that?

Hey, I didn't claim it was exhaustively complete :-)

I have not used any appimages or flatpaks much. If I am using a program and it is not available on my new install, I'll remember to install it when I look for it.

For source compilation, it's frequently for a once-off use (maybe the repo software is too old, so I compile the latest). Mostly, when I move to a new version I don't need to recompile from source.

Since you're already keeping a text file, have you considered using nix (the package manager) to declare all your software packages?

If you don't want a package cluttering up your system, but also don't want to forget about its existence you can just comment it out.

No, I haven't. I know there's package managers that help you keep track of what's installed, and tools that help you easily see what you've done. I just find putting a line in a text file with what I did right after I did it is less convoluted and doesn't really add to what I have to do. Automating it sounds nice in theory but actually doing it is messy and convoluted in practice.

A usual line for an install is the package name, the package type (flatpak, appimage, tarball, AUR, deb, etc) and a description of what the package is. Not much longer than the command I typed in to install.

I also keep notes on changes to the system, services created, paths changed, firewall rules, detailed notes on big things and stuff like that. Any time I run into something weird I reference it and make sure it's not something I did before I go hunting for a solution.

Maybe script(1) would helpful to you? [0]

[0] https://linux.die.net/man/1/script

  > I'm in the habit of keeping a text file with all software I've installed and updating it immediately.

I'll share mine if you share yours. Mine is mostly geared towards Python and PHP development.

> Is there such a thing as a TUI launcher out there? Something that allows fuzzy search of program names, tags and a short description (using something akin to .desktop files for the application metadata). Then, when I suddenly need a program for a certain task, I don't have to hope I memorized the correct command. I just open my TUI launcher, type something related to my task and get a list of some TUIs that could help.

    $ apropos -a data term
    fidentify (8)        - Determine file type using PhotoRec database
    Pod::Text::Termcap (3perl) - Convert POD data to ASCII text with format escapes
    sql (1)              - execute a command on a database determined by a dburl
    termcap (5)          - terminal capability database
    terminfo (5)         - terminal capability data base
    tput (1)             - initialize a terminal or query terminfo database
    vd (1)               - a terminal utility for exploring and arranging tabular data
    visidata (1)         - a terminal utility for exploring and arranging tabular data

My first computer had a TUI launcher. It still does for old times’ sake actually. I found someone else’s screenshot of it running in DOSBox here: http://www.racketboy.com/forum/viewtopic.php?p=1125643 Kind of funny: it has a Y2K problem. The year is 118 in the screen shot. (99 is 1999 and 100 is 2000.) It doesn’t have the search you’re asking for. You would manually organize them yourself instead.

> Something that allows fuzzy search of program names, tags and a short description (using something akin to .desktop files for the application metadata).

What’s the problem with writing a .desktop file for a TUI app? Make the exec line open a terminal and run the app in it. If you want to open the app in place you could probably have the exec line determine the focused terminal and send a command to it to have it run the app.

In fact, I thought this was already a thing; I'm pretty sure last time I was on a DE with an application menu, it had ex. htop in there.

Here's htop's .desktop file: https://github.com/htop-dev/htop/blob/main/htop.desktop

I create symlinks in a ~/bin directory for things like this, so that I don't forget about them.

Aside from the other suggestions --- having a standard "these are the tools I always install", a personal information file (served off your local system as a web page if you wish), system documentation (man, info, aprpos, or Debian's excellent and underappreciated dwww (available of course on any APT-based Debian-derived Linux variant), you could always write your own menu system to invoke or remind you of tools.

In practice, I find that there are a handful of various "swiss army knives" I return to again and again. Some of the new tools are indeed impressive, but an be implemented or offer features available in other utilities.

For myself, "apropos foo", "apt search foo", and the DDG bang "!dpkg foo" are almost always excellent starting points. Debian packages somewhere north of 70,000 individual software packages these days, and will almost always have a tool to do a specific job if not the tool you're looking for.

And yeah, the kids these days are using flatpacks and pip and nodejs and rpm (not to be confused with RPM), etc., though back in the day we had CPAN to deal with. (It still exists, of course, it's just less significant.)

In MacPorts I do ‘port installed requested’ which shows me every package I’ve installed directly, versus as a dependency. You could alias this to something more convenient. For brew I’m not sure.

brew bundle dump; cat Brewfile

That's a good idea - discovery is important.

A launcher could also be a "standard" middle layer that defines common key bindings for tasks that people prefer different TUI applications for (e.g. "m" --> mail - whether it's "mutt" or "mail" or "sup-mail" or "pine" behind it).

I don't use one at present, but took the short cut to define 1-letter shell aliases for some of the more common ones:

e: _e_dit <file> (Sublime)

n: _n_ote taking (own system)

m: new e-_m_ail (sup-mail)

p: show processes (htop)

Why not just keep a misc.txt file somewhere with notes on this if you don't have a regular note keep like Obsidian or emacs org mode.

"Is there such a thing as a TUI launcher out there? Something that allows fuzzy search of program names, tags and a short description (using something akin to .desktop files for the application metadata)."

I've been looking for GUI launcher/software-catalog solution for Windows with those characteristics.

Still haven't found any.

I am building exactly this TUI, the main menu.. It will take me a while longer but I'll post here when it is ready.

I made a page in my personal blog listing useful tools to solve this problem.

Would you mind sharing the link? Thanks.

The highlights are lnav htop ranger and nvim

I'm not sure. It sounds like a genuinely neat idea for another TUI app though! Make the files .text too files instead and build and index of them for searching.

Why would you ever need a launcher for a TUI? If it's in your $PATH isn't that all that's required?

There's a lot of stuff in your path. On a reasonably rich system, hundreds or thousands of executables.

Sometimes it's useful to have a subset, which is what a menu does.