Is there a way to support two layers of sub-commands? about getoptions HOT 1 CLOSED

Hi,

I have not tried this, but it should already be supported.

e.g.:
command sub-command1 sub-sub-command1

Supplemented it with options/arguments to make it look like follows:

command [global-options] sub-cmd1 [options-for-sub-cmd1] sub-sub-cmd1 [options-for-sub-sub-cmd1] [arguments] 

To parse it, we need to perform three parses.

First parse (for command):

command [global-options] <sub-cmd> {doesn't care about the rest}

Second parse (for sub-cmd1):

sub-cmd1 [options-for-sub-cmd1] <sub-sub-cmd> {doesn't care about the rest}

Third parse (for sub-sub-cmd1):

sub-sub-cmd1 [options-for-sub-sub-cmd1] [arguments]

In other words, the number of subcommands+1 parser definition is required. Defining this in a single shell script would make it hard to read, but if we were developing something large enough to require this, we will separate each subcommand into its own file. In other words, the parser definition is defined in the main shell script and in the shell script for each subcommand.

See also #16.

from getoptions.