maneyko / argparse.sh Goto Github PK

If a short value is longer than 1 character, it causes weird parsing rules. If this is a rule, then maybe it should warn because it's a hard to track down bug in this case.

I think it should either accept short options larger than 1 character (after all they are inside [] brackets so we can know exactly how long it is, or else we should not accept anything greater than 1 character. There's no clear error when not sticking to the desired behaviour.

Here's what breaks parsing:
arg_optional "[milestones-file] [mf] [Use this as a list of input milestones.]"

I have had a case where I forgot to add a closing ]" in my argument string.

It caused some weird problems that took me a while to debug.

I am thinking that it would be a great idea to gracefully handle this case. I think in the case of any argument passed it should automatically close it with a ] in the case that the user forgot to pass it.

arg_array "[build-file] [f] [Local file to copy to upstream repository."
arg_optional "[tags-access-token] [t] [Used for pulling this repo latest tag from Gitlab API."
arg_boolean "[no-gitlab-tags-api] [d] [Do not try to use tags api if tags-access-token is passed."

we could do a check by adding a simple:
[ "${str: -1}" != "]" ] && str="${str}]"

I found that long command line arguments are currently case sensitive.

I suggest to update the parsing so that the long command line argument should be converted to first uppercase both the argument passed and the argument to parse, that way we can compare in a case-insensitive way.

Here are two easy ways
Using tr
echo "$str" | tr '[:lower:]' '[:upper:]'
Bash only method
echo ${str^^}

I would like to pass arguments multiple times...e.g. -d for directory
./myscript -d test1 -d test2

Is this supported?

Sometimes I have a problem where I will modify the script arguments. For example, originally I had --foo and I change it to --bar. But the script accepts -foo and doesn't tell me anything so I need to do some debugging.

It would be great to have a magic variable that I can check to show some useful errors. So in the above example:
EXTRA_INVALID_ARGS=("--foo")

That way I can loop through them and warn the user that these are not valid command line arguments.

If possible, I would like to support "=" after arguments as well as double quote support? This is a standard way of passing arguments and makes it easier sometimes than relying on spaces.

e.g. it would be something like:

• --repo-url=git://[email protected]
• --repo-url="git://[email protected]"
• "--repo-url"=git://[email protected]
• "--repo-url"="git://[email protected]"

Can I pass required arguments? e.g. user must pass -d or script shows error.

Is it possible to add argument checking? What I mean is lets say we have:

arg_optional "[repo-url]               [r] [Url for the upstream repository.]"
arg_optional "[readonly]               [r] [Readonly for upstream repository.]"
arg_optional "[repo-url]               [d] [Url for the downstream repository.]"

In this case, I have two short arguments that are the same and two long arguments that are the same. I think that the library should do a basic check and bail out in this case because it could cause unintended behaviour. I have no way to check this during my normal argument checking phase.

Obviously this is a mistake, but with large programs the short arguments especially are quite difficult to keep track of.

My other suggestion would be to spit out an error when any invalid argument strings are parsed. e.g. these would error:

• arg_optional "[[]]"
• arg_optional "]"
• arg_optional ""

I need to use the [] characters in my description. I am specifying a default value e.g.

arg_optional "[grep-regex-pattern] [b] [Grep regex pattern to use when searching files. Default: [[space]]+]"

Could you specify an escape character or some way so I can use these characters in the description?

I have some long arguments and descriptions. For example:

optional arguments:
  -f, --build-file         Local file to copy to upstream repository.
  -u, --remote-file        Name and path of the file in upstream repository.
  -t, --tags-access-token  Used for pulling this repo latest tag from Gitlab API.
  -r, --repo-url           Url for the upstream repository.
  -p, --repo-access-token  Access token for the upstream repository.
  -b, --repo-base-path     Base path to use in upstream repository.
  -h, --repo-app-versions-file Filename in repo containing app versions. Default app_versions.json.
  -d, --no-gitlab-tags-api Do not try to use tags api if tags-access-token is passed.
  -e, --no-app-version-check Disable checking app version matches git repo tag version.
  -n, --repo-pull-submodules Pull upstream submodules after cloning.
  -d, --no-repo-version-update Disable updating of the app_versions.json file. This is not recomomended.
  -s, --silent             Silence all log messages.
  -v, --verbose            Show verbose log messages.
  -h, --help               Print this help message.

It would be nice if the columns and text were all aligned together. column is the command line tool for this.

I understand that you might not want to add dependencies to the script, so in this case, I could suggest two options:

1. We could write a bash only tool like column (this seems a bit wasteful but is an option)
2. We could add an optional dependency by using a command line this:
   command -v "column" >/dev/null 2>&1 && COLUMN_INSTALLED=true if it's installed we could use it for formatting, if it's not installed we can use the current formatting.
3. There could be a way for me to parse the help output somehow so I can do some formatting myself.

I think my preference is 2 if your ok to add column as an optional depdency.

There has been a couple of cases where I've accidentally left out a short argument and it has broke the parsing a bit.

It would be great if the short version of arguments and description were optional. And also, if I could provide more than one short argument.

So I am thinking these cases would all work

• arg_optional "[repo-url] [url] [u] [Url for the upstream repository.]"
• arg_optional "[server-url] [Url for the server.]"
• arg_optional "[password]"

This works fine
arg_optional "[milestones-input-file] [m] [Use this as a list of input milestones.]"

-m, --milestones-input-file Use this as a list of input milestones.

However using this causes help text to disappear and screws up parsing
arg_optional "[milestones-input-file] [Use this as a list of input milestones.]"

Help shows up like:
-Manually, --milestone-title

And this (which I think should be handled) also has some funny results
arg_optional "[milestones-input-file] [] [Use this as a list of input milestones.]"

Help shows up like:
-, --milestones-input-file Use this as a list of input milestones.

Argument descriptions with % in them cause printf to parse wrongly. printf tries to parse them so they need to be escaped.

Here's an example that breaks parsing
arg_optional "[foo] [f] [Percentage of something. Default is 100%.]"