[docopts alternative] provide name mangled compatible for docopts

[Sylvain303]

Following docopt/docopts#35 : this is a twin issue with the project docopts - twin docopt/docopts#36

docopts use can use global vars with or without prefix the names in the option are converted to mangled names (code here) (which is compatible to old python's output, old code here)

Current docopt.sh code

docopts README describing the manged argument conversion.

In order to improve compatibility we need to output compatible variables name from docopt.sh

Usage could be:

DOC="
Usage: pipo new [--switch <value>]
"
DOCOPT_COMPAT_DOCOPTS=mangled
docopt "$@"

compatible Outputs:

new=true
switch=true
value='some_value'

[Anders Ingemann]

Should be fairly easy to implement. However, I have plans to support bash4.2 assoc output like docopts does. I suggest that instead of investing a lot of time into implementing and testing each others mangling schemes we simply say that compatibility is supported for bash4.2+ by using associative array output, where parameter names do not need to be mangled.

[Sylvain303]

Some times ago, I had an interesting discussion with a macOS user using default bash from MacOS X which is bash3.2 because of GPLv3 of bash higher version, and apple not wanting to share their code.

As docopts was originally (before I take maintainers role) supports both global and assoc array for bash, I still support both. And as I also have another output for --no-mangle I can add other output formater quite easily (already done in this branch).

Bash assoc array syntax is a pain. I really understand users still using globals instead. I would discourage you to only support bash assoc syntax. One real advantage to have assoc is that you can extract all parsed argument from docopt syntax from keys of the assoc array, with this ugly syntax: ${!myassoc[@]}

I mainly proposed to support each other mangling scheme to pass our example between both project. I coded a compatible example prototype here. The explanations are in the wiki here.

The idea is that without too much care of rewriting all our existing examples, with can switch and compare behavior between the two projects.

I just propose a kind of wrapping output, and of course I test the cross project method, which is the most interesting human part. 😉