Optional arguments *before" required arguments?

[codevogel]

I am making a cli tool in which it would make more sense to have the optional argument followed by a requirement.

It's an alias manager, so I want to do something like

tmt --add [alias] path

In the above example, the required argument is the path (you need a path to cd to). The [alias] is optional as if you leave it out, you can go to that path using the index of the entry (e.g. if it is the first path added, it automatically aliases 1, if it's the second, 2 works as an alias, etc)

Because I store the entry as alias:path it makes more sense to me to have:

--add /some/path just adds a path
And
--add myDir /some/path adds the path and aliases it as myDir

I don't think this is currently supported when I look at the command docs. Is this correct? If so, is it going against any ideas or could this be made into a feature request?

Current workaround
What I am currently doing is setting a default for path to something like ALIAS_IS_PATH so that I can then in my add_command.sh script check if it equals that default, and in that case reassign path to the alias.
Seems a bit hacky though!

[DannyBen]

No, this is not supported, but there is an elegant solution if you are willing to consider a different (and more common) usage pattern.

Using optional positional arguments before required positional arguments (i.e. mycli [ALIAS] PATH is bad form in my opinion.
I do not know of any command line utility that does that, and if there is, it is a very small minority. Using such a syntax requires counting the arguments to determine if the first one is ALIAS or PATH.

Now, if I understand you correctly, you want to accomplish this:

1. Have tmt ALIAS run something that is associated with the alias
2. Have some intuitive way of adding a new alias from the command line, with required path and optional alias.

I would like to propose the following target usage:

# Running
$ tmt run myalias                # run myalias
$ tmt myalias                    # same, invoking the `run` command implicitly

# Adding
$ tmt add /path                  # add path using a default (indexed) alias
$ tmt add --alias myalias /path  # add path using a specific alias
$ tmt add /path --alias myalias  # same, order doesn't matter
$ tmt a /path                    # using the `add` command alias

If this (or similar) usage is acceptable, it can be done using the command.default option in bashly.

Here is a sample bashly.yml that accomplishes the above.

name: tmt
help: Alias manager
version: 0.1.0

commands:
- name: run
  help: Run an alias
  default: force  # Makes any unrecognized input to be passed to this command
  args:
  - name: alias
    required: true
    help: Alias to run

- name: add
  alias: a
  help: Add an alias

  args:
  - name: path
    required: true
    help: Path to add

  flags:
  - long: --alias
    short: -a
    arg: name
    help: Alias to use

  examples:
  - tmt add /some/path
  - tmt add --alias dev /some/path

[codevogel]

Thanks for the suggestion. Though I guess I'll stick with my hacky workaround where I check for a default value, and then get the actual value for path from the alias.

You make good points but in this case I think I prefer brevity of tmt add alias path over the clarity of something like tmt add --alias alias path or tmt add path -a alias.

[DannyBen]

I understand.

Perhaps another option would be to have tmt add alias=path and then you just split the input at = (or :).
Of course there is the option to choose the required-before-optional path and do tmt add PATH [ALIAS]

[codevogel]

The reason I was trying to refrain from doing something like tmt add alias=path is because it breaks standard autocompletion for entering the paths. At least in my shell, when pressing tab after entering something like alias=path/to/so it will not autocomplete to alias=path/to/someDir. Separating the arguments gets that working without the need for any additional work, like writing custom auto-completions. I'm honestly not even sure where to start on those.

I like the work you're doing here though, and I understand why this is not supported. I'm totally fine with making this hacky exception, as you explained very clearly why that should be an exception 🐦

[DannyBen]

because it breaks standard autocompletion

Yup. The = is autocomplete-killer. We attempted to deal with it in the completely gem in this issue (and associated PR) but it proved to be problematic, not only for us.

I'm totally fine with making this hacky

I would like to be able to provide you with a non-hacky way to achieve what you want, but in order for me to do so, the expected usage patterns that you have in mind should abide by some common practices, and/or be easy to implement in bashly. So - if you come up with other acceptable usage patterns or have another idea on how to make this easier for your use case, I am open to discussing further.