6 ms·
I like the low-power aspect of TUIs, but the problem I have with using them over GUI software is there is no launcher or start menu functionality for TUI (re)di
by muwtyhg 5y ago
I like the low-power aspect of TUIs, but the problem I have with using them over GUI software is there is no launcher or start menu functionality for TUI (re)discovery. I'll often find a cool TUI posted here, install it "for later" and then proceed to forget I ever installed it. When "for later" finally comes around, I have to guess the name using tab completion or open my browser, search my history and hope it's there.
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.
- pseudoramble 5y agoI'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.
- betwixthewires 5y agoI'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.
- RehnoLindeque 5y agoSince 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.
- betwixthewires 5y agoNo, 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.
- oso2k 5y agoMaybe script(1) would helpful to you? [0] [0] https://linux.die.net/man/1/script https://linux.die.net/man/1/script
- oso2k 5y agodmenu 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 https://github.com/lpsantil/slmenu [1] https://github.com/lpsantil/slmenu-todo https://github.com/lpsantil/slmenu-todo [2] https://youtu.be/SlJto75auCA https://youtu.be/SlJto75auCA
- betwixthewires 5y agoWhy not just type the command you're trying to type and tab autocomplete it?
- oso2k 5y agoI 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/ https://tools.suckless.org/dmenu/scripts/
- sva_ 5y ago> 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'
- lelanthran 5y ago> 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.
- betwixthewires 5y agoHow do you keep track when installing appimages, flatpaks, tarballs, compiling source and things like that?
- lelanthran 5y ago> 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.
- II2II 5y agoIt'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.
- dotancohen 5y ago> 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.
- idle_zealot 5y ago> 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.
- yjftsjthsd-h 5y agoIn 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.
- user3939382 5y agoIn 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.
- mekster 5y agobrew bundle dump; cat Brewfile
- deleted 5y ago[deleted]
- drivers99 5y agoMy 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 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.
- totetsu 5y agoI made a page in my personal blog listing useful tools to solve this problem.
- stjohnswarts 5y agoWhy 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.
- jll29 5y agoThat'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)
- cellularmitosis 5y agoI create symlinks in a ~/bin directory for things like this, so that I don't forget about them.
- openfuture 5y agoI am building exactly this TUI, the main menu.. It will take me a while longer but I'll post here when it is ready.
- severine 5y agoHere's htop's .desktop file: https://github.com/htop-dev/htop/blob/main/htop.desktop https://github.com/htop-dev/htop/blob/main/htop.desktop
- BugWatch 5y ago"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.
- yrro 5y ago> 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
- dredmorbius 5y agoAside 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.)
- 0xdeadb00f 5y agoWhy would you ever need a launcher for a TUI? If it's in your $PATH isn't that all that's required?
- dredmorbius 5y agoThere'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.