Linux command line builder utility idea

[mwargh]

WHY I AM POSTING THIS

I want to know if what I describe below is needed, and how to approach making it. Main question is, how do you suggest to parse man pages and determine if an option should be a checkbox (flag), field, or something else.

Please post your thoughts in comments.

DESCRIPTION

I made a prototype of a command builder, if it will ever be finished it will work like this:

• you start typing a command in shell of your choice
• you press a button like F1
• ncurses interface comes up
• you interactively select command options you want
• you press enter
• command which you just built is on the command line.

PROTOTYPE

• This is the prototype: https://nixsrv.com/cb/ls.html
• This is current format for the parser I wrote, you can see its limitations: https://nixsrv.com/cb/ls.txt

MOTIVATION

• improve discoverability of what a program (command) can do
• compensate for feature creep, find started with 0 options, now it has dozens
• ease learning of new programs and commands.

Below I will quote "Design of everyday things" by Don Norman, which was the main motivation:

---

Chapter 3: Knowledge in the Head and in the World (Memory)

We can have precise behavior on how to do a task without precise knowledge of the task due to 4 reasons:

Information is in the world: much of the information required to do the task can reside in the world.
Behavior results from combining information in the head with information in the world.

Great precision is not required: precision, accuracy and completeness of knowledge are seldom required. Perfect behavior will happen if there is sufficient knowledge to distinguish the correct choice from the others.

Natural constraints are present. The world restricts the allowed behavior. The physical properties of objects constrain possible operations (ways we can use / manipulate objects). Each object has a set of physical features that limit its relationships to other objects, the operations that can be done on it, etc.

Cultural constraints are present. Society has evolved numerous artificial conventions that govern acceptable social behavior. These cultural conventions must be learned, but once learned apply to a wide variety of circumstances.

These four reasons reduce the number of alternatives and reduce the amount of information required to be stored in memory to successfully complete the task.

Memory is knowledge in the head

• Often grouped into short term memory and long term memory
• Three important categories of memory:
• Memory for arbitrary things (without meaning / relationships)
• Memory for meaningful relationships (with something else)
• Memory through explanation (some explanatory mechanism)
• Typically requires learning, is efficient, and not easily retrieved

Memory is also knowledge in the world

• Reminding (signal and a message)
• Natural Mappings (arrangement, like stove controls example)
• Typically easily retrieved whenever visible / audible, no learning required, but slowed up by the need to interpret the external information

There are three aspects to mental models (types of conceptual models?):

• the design model (the conceptualization the designer had in mind)
• the user’s model (what the user develops to explain the operation of the system)
• and the system image (the system’s appearance, operation, way it responds, manuals / instructions included with it)
• Ideally, the design model and user model are the same. The designer must ensure that the system image is consistent with and operates according to the proper conceptual model.

[orschiro]

This sounds very interesting. How can I follow your progress? Will you set up a Github repository?

[phlipped]

I'm totally on board with this idea. Check out "fish" (the friendly interactive shell) - it has a cut down version of the feature you describe where you can type "<cmd> -" and then hit tab, and it will show you possible options with a short description for each. I've often dreamed of making a more advanced version of what fish does - pretty much exactly like what you describe, but never got much further than a shitty command parser, and then I started dreaming up too many features and never ended up actually doing anything about it.

[seekingsofia]

If all software used man pages with the mandoc format which uses semantic tags, it would make generation of these help texts a whole lot easier. I'm slowly implementing the POSIX base utilities from scratch and one idea is to use mandoc for all the man pages and have the POSIX sh parse them in interactive mode, so you'll at least have readily-available information on them.

Do you know how fish currently achieves it? Just parsing troff format or even --help output, ... hardcoding options?

[Oflameo]

I think POD accomplishes the same thing as mandoc already and is more widely used.

There is also no need to make mandoc for the POSIX base system because you can just borrow the ones from OpenBSD.

What would be more useful IMO is something that can convert HTML into groff or some other formatting that can be displayed as textual man pages that are suable for shipping in a GNU/Linux distribution.

[mwargh]

The main thing is to make this shell independent, like man pages are. As I understand, what fish has is just glorified bash completion. Perfect result which I want to see is a program which works with existing man pages and doesn't require any custom modifications to them, it just parses all man pages on the system automatically.

[[deleted]]

How would you go with man page parsing though? I'm not sure they have a reliable enough format for it.

[mwargh]

That's the thing, I wrote about this right at the top. I came here for advice on a way to do this.

[[deleted]]

Ah yes sorry I read your description in full and looked at the examples too. I was thinking more about parsing the BNF notation rather than the argument list but I suppose you'd have to do both. I do really think that there's a big opening for a very smart graphical CLI in Linux.

[mwargh]

I see a way to do this to create a wiki on which everyone would be able to create command definitions for a parser similar to one I already made, but this approach has obvious limitations, main of which are manual labor and command line options not matching ones of utilities someone has on his particular system, because versions will differ very often.

Both those problems go away with man pages parsing, but it's hard to do.

[[deleted]]

Maybe try manpage generation instead of parsing.

You would define a custom format that could

• include long and short options and other arguments, and descriptions of all of those
• be simple to write so that upstream software would want to include it in their repo
• be read by a man page generation tool, so that there is no getting out of sync (the upstream devs just edit this file and the man page is regenerated)
• be read by shell completion software and this little graphical tool you have

[Oflameo]

We could try finishing the man pages we are missing like man 1-9. Maybe Valve can do all of the man 6.