Future direction for Linux 4512

Not all of the Linux community wants to achieve this - some are happy that it works for them. But it seems that your real goal is to improve the usability of the CLI.

These days for the simplest of users, Linux and Windows have comparable usability. Just because it's mainly used as GUI-only doesn't make Windows configuration-free or completely intuitive. The CLI problems of Linux are offset by other problems in Windows (e.g. the registry, the need for virus checkers, defrag, etc).

Snip exposition of the difficulties of the newbie in navigating manpage help

So paraphrasing, the question you're posing is: how do we make the CLI more user-friendly for the newbie and the casual user who may only use it infrequently or when forced to, without disadvantaging the advanced user?

You make a few suggestions below which I'll comment on, but I think the answer is not wholesale changing of filenames and options. After all, as Michael Heiming writes in his post, compatibility with POSIX-SUS standards is important.

Instead, I think the best approach would be to provide a default interactive shell for such users (and anyone else who chooses to use it) with these features:

1) Improved help system. The "info" command was supposed to be the improved version of "man", but I still find it deficient. I don't use emacs and find the navigation keys unintuitive. The complete novice will fare worse than me. A great newbie-friendly help system would be categorised (Filesystem, Dealing With Processes, etc) into a cross-referenced hierarchy and would include how-tos as well as a flexible search system (ala Windows' help searching but better).

2) Command-line building. Most modern shells offer auto-complete on pressing tab. That's nice, but a really newbie-friendly CLI would also tell you:

a) what each command does b) what options each command supports

and would feature

c) context-sensitive auto-complete. e.g. after typing the space after ifconfig then pressing an auto-complete key, the completions could be based on a list of available network interfaces.

The information required to support a, b and c would be stored in a configuration database - either one per command or one for all commands. Creating this database would be the real grunt work but once you had it there would be all sorts of powerful buttistance that you could offer the user. Some other useful command-building features could be "templates" or "wizards" to use some Windows terminology. They would construct shell scripts or pipelines to complete common tasks, such as search and replace in a group of files using sed, or finding a string in a set of files using grep. Another useful tool would be a regular expression builder.

3) Some visible cue eg. an always visible menu. This is because it's easier for a newbie to select from a menu rather than attempt to remember what to do.

I don't know how much of the above three features are already implemented by existing tools. I've heard of git and mc but haven't used recent versions of either. Conceivably they or other tools do a lot of this already. The nice thing about this approach is that it doesn't require changes to the current naming scheme and it doesn't hide anything from the user - it simply makes it easier for them to achieve, or to find out how to achieve, a given task.

Shell aliases or soft-hard links can achieve this.

Agreed that the CLI help system could be improved for new-casual users.

Because there are multiple shells.

Because there is an existing base of sh-bash scripts and it is useful to script in without having to resort to an external program like Python. Also because shells and shell scripting are a part of the POSIX-SUS standards.

Sure, and this is already done in a lot of manpages. There need be a reasonable limit though as some commands have been in improvement for years or decades and a detailed history would take over the page. Some authors want to be anonymous too.

Unless you bring out your own distribution there's no way you can mandate the changes. This could better be handled using "option aliases" in an extended shell such as one with the features I described above. The aliases would be similar to command aliases but would apply to a single option of a single command.

If you're interested in developing a tool or extending current tools to provide the features I described I'm willing to provide advice - and possibly active help. I would find the auto-complete and context-sensitive features very useful myself.

A worthwhile goal if you're committed.

--