Idea for a feature: Allow some CLI features to be configurable - enable/disable history/autocomplete/escape sequences

[TheColector]

Background

I am utilizing embedded-cli to drive functional hardware tests via Python. Currently, the presence of escape codes adds some unwanted "noise" to the received data buffer + features like history and autocomplete are not needed in such use-case.
It's not that one can't deal with some input sanitization and parsing on the controlling entity's side, but if a dedicated and simple configuration would allow for turning these things off, one would not have to take care of it at all.

New feature proposal

I would like to propose a mechanism that would a user to selectively turn some features off in case one does not need them.

When some these features are turned off, CLI should behave in the following manner:

1. For input part, history of commands and autocomplete is not enabled, it's just a plain echo-like behavior until line termination is received
2. For output, only what user decides to send to the CLI output is printed - i.e. no escape sequences

Furthermore, I suggest that the following attributes should be exposed to a dedicated configuration layer (e.g. CliConfig.h or in main header):

• What line termination is appended at the end of a command (e.g. "\n" vs "\r\n")
• Invitation prompt selectable by a user (default one is "> "
• Configuration to selectively turn some features off (maybe with one that enables minimal CLI where bare minimum is offered - automation friendly)

I'm doing the above regardless for my own needs but I wanted to share the idea.
If that is something that would be welcomed, I could make a PR once it's ready.
Keep in mind that the above is just a rough concept so it's still in rather early phase in my head.

As always, I'm open to any suggestions and ideas.

BR,
Michael

[funbiscuit]

That's a good proposal, but "the devil lies in the details". I wasn't able to figure out a good configuration option to make such things possible in C that will be easy enough to configure and develop. Throwing ifdefs here and there is a bad approach that is hard to maintain.

Proposed things were much easier to implement in more modern language like rust (see embedded-cli-rs). But now that project is also kind of abandoned since I don't have time to maintain it properly.

Lately I've had another idea - to build a cli generator. Simple cli utility that reads custom config (for example yaml) with something like openapi schema but for cli. And then it just generates necessary C code to make things work. This allows to generate code that targets specific needs of an app and parses only things that are necessary. Unfortunaly, as you may guessed it, I don't have enough time to finish this utility and release it. And so I didn't touch it for three months.

Here's an example of such schema, you can probably guess what each parameter does:

cli-api: 0.1.0
commands:
  status:
    summary: Show current status
  hello:
    summary: Print hello message
    args:
      - name: name
        description: Person
        schema:
          type: string
  led:
    summary: 'Control LED'
    commands:
      get:
        summary: Get LED status
        options:
          - name: verbose
            short: v
            schema:
              type: boolean
      set:
        summary: Set LED brightness
        args:
          - name: value
            required: true
            schema:
              type: integer
        options:
          - name: dry_run
            schema:
              type: boolean
  adc:
    commands:
      read:
        summary: Read value from ADC
        options:
          - name: retries
            short: r
            schema:
              type: integer
            default: 3
generator:
  externalFunctions:
    writeByte:
      name: cliWriteByte
      args:
        - name: b
          type: uint8_t
    flush:
      name: cliFlush

With such generator approach it will much easier to make everything configurable. Since in high level language you can write arbitrary hard code and don't think much about memory an such. While generated code is low-level and has low memory footprint.

Maybe I'll give this generator another chance and try to release 0.1 version is some future.