Is it possible to provide custom `help` functions in case of wrapper functions? about bashly

[DannyBen]

One more thing, by the way.

If you are just looking to create some sort of "predefined commands" for docker (with or without variable substitution in the commands), you can also consider using one of my other bash productivity tools:

• opcode - lets you define commands in an op.conf file, and execute with op <command> <args>. This is designed to be a user friendly Makefile alternative.
• alf - bash alias generator with "sub-alias" support. I am using it heavily to have my own docker (and git and many others) subcommands. See for example my docker related bash aliases defined in alf, which can be executed with d instead of docker.

[DannyBen]

I don't understand the use case.

[RonnyLV]

For example, I have a separate program that is being wrapped in a command by bashly and thus it has it's own documentation and execution.

The wrapper is intended to fulfill all runtime necessities, like all environment dependencies for the external command.

Let's say, I want to wrap docker program in a script that prepares environment variables

name: console
help: Console
version: 0.1.0

commands:
  - name: docker
    catch_all: true
    help: Docker wrapper

# docker_command.sh
docker -e MY_CUSTOM_ENV="foo" ${other_args[*]}

In this case, if I run ./console docker --help it will run the bashly's generated help

./console docker --help
console docker - Docker wrapper

Usage:
  console docker [...]
  console docker --help | -h

Options:
  --help, -h
    Show this help

But I want to be able to mark the --help of this command to not be processed by bashly

[DannyBen]

Hmm. Seems like a weird and confusing edge case.

Wouldn't a help subcommand be better?

name: cli
help: Sample application

commands:
- name: docker
  short: d
  help: Run docker
  catch_all: true

  commands:
  - name: help
    help: Show docker help

[RonnyLV]

In case of help subcommand, I cannot run parent as an individual command.
Also wouldn't it mean that I should write wrappers for all docker program's commands?

[DannyBen]

I am not 100% clear on what you are trying to do, probably.

Are you trying to create a bash script named docker to wrap the real docker? If so, I would advise against it.

If not, and you are just trying to build a utility that sets some environment vars or does other things before delegating the entire command line to the real docker, then I feel that the below guidelines apply:

1. If someone wants docker help, then can just run docker --help
2. As a convenience, they can run yourscript docker help which will just call docker --help
3. Your help function can do whatever you need it to do - including, for example, allow yourscript docker help build or yourscript docker help pull.
4. The syntax yoursript docker build --help will not be supported by your app - it is confusing anyway, since...
5. ... the --help flag is always, in any other CLI, responsible for showing the help of that CLI.

Now - despite the fact that my intuition says you should avoid overriding the *_usage functions, a part of me sees a small chance that this could be useful, so - lets explore this further for a second.

As it happens, if a bash script contains two functions with the same name, the last one will be the one that is used. This "feature" allows you to actually "override" any *_usage function by simply putting it in a lib subdirectory.

Can you try it?

Run bashly add lib to initialize a lib subfolder.
In it, you can create a file with the same name as the usage method you want to override, and write that override function in it.

Remember that all files in lib (even in subdirectories) are added to the script as is, so you can even put these override functions in lib/usage/*.sh.

I am not saying this is the most elegant thing (since you will have two functions with the same name in the script), but for the sake of discussion at least - is that solving this use case?

[RonnyLV]

The second scenario with library inclusion works, it's the way I already implemented it, but the fact that there are duplicate functions in the output is a bit confusing.

About the first scenario, on the second thought it would actually work fine too, but I'm not able to run other commands ./console docker [docker command] besides of ./console docker help in case of this configuration:

name: console
help: Console
version: 0.1.0

commands:
- name: docker
  short: d
  help: Run docker
  catch_all: true

  commands:
  - name: help
    help: Show docker help

[DannyBen]

Right. Yes, this wont work, since once we added a help command, the entire script switched to command mode and is now console [command] [<catch_all>...].

What is the real use case? Are you trying just to set up environment variables before running docker? If so, it feels like an overkill.

If not, and you are also adding your own args or flags, like console docker build --production IMAGE then in any case, you already have to add a console docker build command code, so you can have something like this:

name: console
help: Console
version: 0.1.0

commands:
- name: docker
  short: d
  help: Run docker

  commands:
  - name: help
    help: Show docker help
    catch_all: true

  - name: build
    help: Build image
    catch_all: true

    flags:
    - long: --production
      short: -p
      help: Build using the production Dockerfile

Note that with this setup you can run:

$ console docker help ANYTHING...
$ console docker build [--production] ANYTHING...

And delegate the ANYTHINGs forward to docker.

This is what I would do, based on the details I understand from your statements so far.

[RonnyLV]

Thanks a lot, I will rethink the solution on your insights.

[DannyBen]

Sure thing. And if you are still not happy with the result, let me know, we can see what is missing in bashly to allow it.

[DannyBen]

I am going to close this, but feel free to comment or open a new issue if you have new thoughts on the subject.