Not sure if this will help you, but I keep just one homescreen page with my most-used apps on it, and I've developed muscle memory for all of them. When I set up a new device, I put the same apps in the same spots. Other than the inherent inaccuracy of touchscreens, I could probably open any of them blindly. I also only fill up the bottom half or so of the screen, so they're all easy enough to reach.

>the argument used to be you used Windows instead of Linux because on Linux you might occasionally have to use the scary terminal to fix an issue

This always annoys me because you're really handicapping yourself by ignoring the CLI on any OS. Sure I use it more heavily on GNU/Linux than I did on Windows as a kid, but that's because it's so good. If I'm ever in front of a Windows machine now I still like to have a terminal handy (and it's even better/more-familiar on macOS, of course), and I've learned things like "type is like cat", "robocopy is like rsync", "tasklist is kinda like ps and taskkill like kill/pkill" which help me to do things better on Windows than when I used it fulltime. I'm glad Microsoft invested more in the CLI with Windows Terminal, OpenSSH in the default install, winget, PowerShell, etc. I think it's better for everyone. I fear the CLI hate is spreading anti-intellectualism. Some people seem annoyed when they even have to use their keyboard instead of their mouse for something.

If CLIs functioned as LLM and you could talk freely with it, there would be no problem. In reality, CLIs are inconsistent and basically function as robotic interfaces, a lot of them not that far of programming.

> If CLIs functioned as LLM and you could talk freely with it, there would be no problem.

On face value, I find this suggestion hilarious. People are having sandboxing issues left, right and center with AI agents and MCPs, so clearly there would be enormous problems with giving an LLM full unscoped terminal access. Remember the guy who had his hard drive wiped?

Do you just mean that the ABIs are inconsistent and you want a more unified way to specify what you want (but the user still more-or-less spells out what command will be invoked)? I have some sympathy for that concern, yes.

If CLIs functioned as LLM and you could talk freely with it, it would kiss your ass while it hallucinates about the files on your hard drives, invent command line switches that either don't do anything or does something other than what you want, and every command that used to take just 5-10 characters would now require you to type paragraphs. No thank you.

GUIs are great for when you're new to a bit of software as you can see the various options and get a feel for the possibilities. CLIs are nearly always more flexible once you've read the man page, but is a steeper learning path.

Automation/scripting is when CLIs really come into their own as otherwise you end up becoming a GUI click monkey. The best is when there's both a GUI and CLI (as long as they work the same way).

I wonder how good CLIs could have been if a fraction of the resources that have gone into GUIs had gone into making CLIs more user friendly. A sequence of words is a pretty natural way of conveying what you want done.

The problem with CLI isn't typing, its discoverability. Keep in mind conveying what you want done requires knowing what can be done first.

I often get my way through unknown CLI commands by just typing TAB and selecting the option that sounds like what I want. Works, most of the time, I don't think that is really an issue. For most CLI programs you also have a reference/cheat sheet, examples and an interactive hypertext systems of tutorials available.

That is exactly the sort of thing I think could have been improved. We have very little at the moment - autocomplete and some help.

Along with the "-h,--help" options, an option to show common usage examples would be useful. I find it much easier to learn from an example as you can modify and build upon it. Otherwise, it's a case of skimming through the man page and then switching back and forth between the man page and the command that I'm writing. (This is most common with tools that I don't use all the time, yet have expert features such as "ffmpeg")

> an option to show common usage examples would be useful.

That's what the man page is supposed to be (and most do contain example) and why GNU wanted to split it into info (tutorials and exhausting documentation) and man (reference and examples).

Yep, the examples on man pages are helpful, but I'd like a slimmed down option to just show the examples and a one-line description for the examples.

I usually end up just doing a quick web search for the command if it's not one that I'm familiar with (i.e. where I have read the man page).

An extreme example of my issue would be trying to find BASH examples of how to process a list of files - the man page on BASH is fairly lengthy.

Meanwhile, Greg's wiki provides this example of processing mp3 files:

  while IFS= LC_ALL=C read -r -d '' file; do
    some command "$file"
  done < <(find . -type f -name '*.mp3' -print0)

Why do you serialize and then deserialize the list of files? Even if you do disable the splitting on reparsing the list, why don't you just do this:

    find . -type f -name '*.mp3' -exec some command {} ';'

That sounds just unnecessary and bug prune. Unless you target some odd platform where find doesn't support '-exec', but it is even in POSIX. I think due to your use of process substitution, your code has a higher chance of being unportable, so why do you want to complicate your code?

Stuff like that is why I personally prefer the man pages to random websites.

Honestly for something as complex as a shell (which describes both a language, an editor, and an implementation) the man page is surprisingly short. (6418 lines for me) I have just found the section on process substitution in <1min, without even using the search, just by reading. I looked it up, because I didn't knew the name of that syntax, so I needed to actually look for what I wanted and I do not use the man page of bash often.

It's to deal with problematic filenames (e.g. containing a newline) and enables setting of variables within the current process. Putting multiple commands into the "-exec" of find is possible, but looks horrible. To be fair, my example didn't use multiple commands, so your version is okay for simple processing.

Don't get me wrong, the BASH man page is great, it's just that I prefer to work with examples.

For reference, here's the Greg's Wiki explanation: https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_....

On my computer

    touch "$(echo -en 'a\nb')"
    find . -type f -name '*.mp3' -exec bash -c "echo '{}'; ls '{}'" ';'

works just fine, but maybe it doesn't work everywhere.

If you don't like how the multiple commands look like, you can always write it like this:

    find . -type f -name '*.mp3' -exec bash -c "
        echo '{}'
        ls '{}'
    " ';'

Yep, you can chain multiple commands with find's "-exec", but I'm not a fan of it myself. I suspect setting variables in the current process is trickier though.

(Very minor nitpick, it should be 'a\nb.mp3' to be included, but that does work fine)

Incidentally, ShellCheck isn't happy with that although I don't follow their reasoning:

  find . -type f -name '*.mp3' -exec bash -c "
                                           ^-- SC2156 (warning): Injecting filenames is fragile and insecure. Use parameters.

https://www.shellcheck.net/wiki/SC2156

The Gopher protocol was made there!

Yes, and I use Gopher as a B/U of my Gemini Capsule. A couple of years ago I moved my site to Gemini with Gopher as a mirror.

I found doing that makes maintenance far easier that what I had to do with html.

Opposite of my experience. I love reading the lyrics and Genius annotations on songs I like. Vampire Weekend has a lot of good lyrics. Reading the annotations for The Black Keys' Turn Blue album was kinda eye-opening, and Kanye has a lot of great memorable lyrics as well. I feel it helps me appreciate the songs more deeply on later listens. Also it kinda bugs me if I can't quite catch some words in a song in the live-listen.

Example:

I Write Sins Not Tragedies - Panic at the disco:

So you're a guest at a wedding and you're eavesdropping and passing judgement on people based on a snippet of conversation. Ruined.

Example:

Going the Distance - He's bad at racing and can't realize it. He's burning real relationships. I'd otherwise love this song.

Years ago my brother pointed out that lyrics are just a form of percussion.

I'm glad they add for you, they typically detract for me.

Not paying attention to the lyrics also les me deal with music as just grooves in a flow state as well.

>I used to spend countless hours tinkering with arch but then I got older and don’t have much time.

Have your lost your old configs that you worked hard on? That's a shame if so. I love moving my configs I've worked hard on to new machines and instantly getting up and running in a now-familiar environment. It saves so much time and effort.

> Have your lost your old configs that you worked hard on?

I mean… it was so long ago. Actually it’s more than 15 years ago, on used hardware no less. Needless to say, I don’t even have remotely the same hardware anymore - I’m on AM5 / DDR5 right now.

>it seems to know when I've run a command in one tab/split while another is open where fzf doesn't seem to sync it all the time.

On my machine this is handled in zsh, not fzf (but then fzf still benefits). You can configure your shells to sync without exiting. You may need to run one command (or just hit enter with nothing typed, maybe) for the shell history to catch up, but then it should all be there. Relevant options:

# share history among terminals

setopt share_history

# append to the history instead of overwriting

setopt append_history

# append to history incrementally instead of when the shell exits

setopt inc_append_history

I think finding out about this is why I originally switched from bash to zsh several years ago.

Yeah I believe I have these already configured as such, it was that atuin didn't require me to press enter again but thank you for sharing

FWIW if you're on a machine where you're allowed to use non-default configs like oh-my-zsh, you could also just copy over your own custom config. It seems like you're implying the alternative to using oh-my-zsh is to rewrite your config from scratch every time or use the default. It doesn't quite add up to me. If you craft a config file of your liking one time, then back it up somewhere, track it with git, whatever, you can keep making use of that config across other machines. I just set up a new personal machine recently, grabbed my dotfiles, now it's the same familiar feeling as my other machine.

> just copy over your own custom config

That already defeats the purpose:

I don't want to copy things around

I never spend time crafting a custom config

Crafting a custom config is right up on the list of things I enjoy. Right up there with creating new characters in video games that allow lots of customization.

I like to re-add the readline binds after enabling vim mode, and then I only leave insert mode occasionally. C-x C-e really is great, though, I think I do tend to reach for that if I need to do a big edit of a one-liner.

This could actually be a reason to work on better supporting older "Android" phones in postmarketOS, to keep the hardware people already have working.