When reading a man page, especially a classic man page like the ps man page or maybe a system call man page like sigaction, I try to keep in mind that the information is there but may require careful study. Good man pages are a often quite terse, requiring attentive reading.

I like using man the best, but there are two other methods that command-line programs can use to provide documentation, GNU's info and built in help (triggered by -h or --help on command-line).

GNU's info works better than man for more complex documentation--its practically a curses based e-book reader. For a taste of using info based documentation, try

  info spell

on the command line to see the documentation for the aspell command. Info is even used as the internal help documentation for Emacs, reachable from inside of Emacs (via "Cntl-h i", naturally). I think rsync has too many facets for a man page and would benefit from having a longer info file that could explain the many use cases for rsync.

I also like `tldr <command>` if a cached version of the internet's advice is needed.

Last resort is Google.

"proper" man page is quite the qualifier. (Edit: as in, I know I'm "supposed" to use man pages, but it's almost easier to google for it. The man pages I've seen aren't as easy to use for common cases).

CLIs are much more limited at discoverability compared to a graphical interface (TUI/GUI) which can show you all the options and let the user directly interact.

Install `tldr`.

I always end up having to google how to do stuff with CLI tools but GUIs let you discover how to do things intuitively. Tried using man pages but they're always slower to find stuff in and a stackoverflow answer is more likely to target the use case I'm going for.

> Tried using man pages but they're always slower to find stuff in

Man pages are presented through less, so you can begin a (regex) search with / and hit n to go to the next result or N to go back.

If you knew this, I am actually very surprised you don't find information near-instantly.

I'm aware, but this involves guessing the right word/phrase and sifting through multiple matches, and there often aren't quick examples given.

> so you can begin a (regex) search with / and hit n to go to the next result or N to go back.

His point of that being slower still stands. I also find that just googling generally what I want can more quickly lead me to a stack overflow post with exactly what is needed, while MAN pages can be rather cryptic at times without reading the whole thing.

And some new CLI programs don't ship with their manpages at all. I've also seen some manpages that don't match the specific version/release of a program installed on the OS.

not super relevant here, but for those interested. There is a cli tool called `tldr` that takes in the name (of a tool) and prints out common usages.

I'm a big fan of this. Probably 90% of the time the tldr summary has my use-case covered.

If the tldr entry exists. Obscure commands don't have one while you're less likely to know these well. Chicken/egg problem.

In my experience the coverage is shockingly good. And if you find a case where there is no tldr, you're back where you're started having lost not more than five seconds. The failure case is graceful, so it was easy to put tldr into my workflow.

I wonder if tldr returns a meaningful exit value that you could write an alias/function for something like tldr $term || man $term

Definitely; tldr returns 0 on success, 1 on failure.

    tldr_or_man() { tldr $1 || man $1 }

> but GUIs let you discover how to do things intuitively.

The real advantage of CLI is that it is a language, not just a UI. It is composable, programable, remote-able and easier to automate.

rsync is one of those tools that I use so infrequently that I’d rather have a good GUI than have to relearn the command switches every time I use it.

Or just script it, include good comments explaining why you used all the switches you used, and back up the scripts to your favorite backup service. Available everywhere and explained well so you don't forget why you choose the switches you did.

Good suggestion here.

I created a single serving Ansible docker image with a couple of playbooks for this very purpose --devs were asking frequently to pull schemas or dump from various data sources internally "Hey I forgot the command to do this, what was it again?".

Eventually I gave them a Dockerfile, wrote up some documentation on how to change hosts in the run command if they so desired, questions all but stopped immediately, and the devs loved it.

I now get a new question "hey, can you make one of those but to do this?"

"Sure, here's a playbook for it, put this in that directory on your local machine and it'll be available in the container". Combined with dynamic host inventories, it's made me a few friends lol

And in the scripts, use the long-form flags, so many comments are unnecessary.

Yeah. Though rsync is not the most option-rich program ever. What really needs GUI is... ffmpeg! :)

There are lots and lots of ffmpeg GUIs, the problem is that IMO, all of them are either (1) not powerful enough or (2) more difficult to use than just the command line.

The first problem may, of course, be a non-issue depending on what you need to do.

Someone with a sufficient itch (and some Elisp skills) could probably do for ffmpeg what the Magit team did for Git. Git's another program with a litany of options, and Magit does an outstanding job of covering them with an easy-to-use interface.

https://magit.vc/manual/magit/

Admittedly the ffmpeg bar is probably higher, esp. given that ffmpeg can be configured and built a couple dozen different ways.

Handbreak is a really good GUI for ffmpeg. The problem is that i (with its ~20 different windows) supports only one use case of the tool.

I'd love to just make a GUI for generating ffmpeg filter graphs. The MS SDK had a directshow filter graph editor (graphedit i think it was called?) that was quite pleasant to use back in the day.

ffmpeg needs a GUI? Nah, you just make aliases or script it as this comment already described for Rsync [1] [1] https://news.ycombinator.com/item?id=20393620

That depends.

Applications that have occasionally used UI MUST BE self descriptive. Their functionality MUST BE consumable without need of reading man pages.

Otherwise they will have very few users.

Computer is for human, but not human is for computer. As its configurational appendage.