unfor19 / bargs

A framework for creating a Bash CLI application.

Hi there 👋

Checkout my website, meirg.co.il, a central point to all of my blog posts and videos, the main topics are:

• DevOps culture and best-practices
• Cloud and On-Premise Architecture
• Programming for both backend and frontend

bargs's Issues

Allow whitespaces in values

Irrelevant

[QUESTION] How are you using this project?

Surprisingly this project got 117 stars, as of writing these lines.

Any chance you can share your thoughts about bargs? Anything that is missing/can be improved? I'm super curious

/root/xyz/bargs.sh: line 173: /root/xyz: Is a directory

It might be a stupid question but i am getting the error in title.The bargs_var ,bargs.sh and my script (example.sh) is in the xyz folder.I am on Centos 8 and i have

source "${PWD}"/bargs.sh "$@" on top of example.sh

[ENHANCEMENT] Arguments Groups

Description
I'd like to declare an argument group and define how many arguments are required from within this group.

For example, a Bash script accepts the following arguments: --happy, --delighted, and --joyful. I want the ability to set how many arguments are required.

• Minimum required >= ${num}
• Specific number = ${num}

Possible solution

• Add attribute type=group, for backward compatibility, it'll exist only for groups
• Group definition structure: type=group, name=my_group, minimum=0, specific=0
• When iterating over bargs_vars, first check if it's type=group. Also, check if an argument is part of a group group=my_group
• If an argument is part of a group, then use counters and compare with minimum and specific
• Default values for minimum=0 and specific=0 means there are no special requirements, and the group is ignored

Additional context

• In future releases, arguments will also possess this attribute type=argument

[ENHANCEMENT] Add a predefined prefix to variables

Description

Currently, bargs exports variables UPPER_CASE and lower_case.

I'm using a very strict naming convention, see Writing Bash Scripts Like A Pro - Part 1 - Styling Guide

Type	Scope	Convention
Environment	Global	MY_VARIABLE
Global	Global	_MY_VARIABLE
Local	Function	my_variable

Using bargs forces me to redefine variables

# Assuming my_global_var was declared in bargs_vars
# MY_GLOBAL_VAR will be available as an environment variable in my script
# So now I need to do this to define it as a "global var"
_MY_GLOBAL_VAR="${MY_GLOBAL_VAR:-"my-default-value"}"

Possible solution

The file bargs_vars contains metadata options for running bargs, so adding options, such as vars_perfix, won't break anything in bargs as it ignores unknown keys.

I'm thinking of adding four options:

1. vars_prefix="" - Defaults to "", adds a prefix to all exported variables.
   • Enables isolating the app from other predefined environment variables
   • Makes it easier to grep all variables that were exported by bargs with, so I used vars_prefix=MY_APP_PREFIX_ in bargs_vars, I could do the following

     env | grep "MY_APP_PREFIX_"
     # results
     MY_APP_PREFIX_GOOGLE_CLIENT_ID
     MY_APP_PREFIX_GOOGLE_CLIENT_SECRET

2. vars_uppercase="true" - Defaults to "true" which avoids breaking previous bargs.sh versions. Setting to false will drop the assignment to UPPERCASED env vars.
3. vars_lowercase="true" - Defaults to "true" which avoids breaking previous bargs.sh versions. Setting to false will drop the assignment to LOWERCASED env vars.
4. vars_type=environment - Defaults to "true" which avoids breaking previous bargs.sh versions. An alternative value would be global, so the variables are not exported with export _MY_VAR="my value", but only declared as global variables `_MY_VAR="my value"

A concrete example implementing the above solution

bargs_vars

---
name=person_name
default="Willy"
---
name=age
default=99
---
name=bargs
description=bash example.sh -n Willy --gender male -a 99
vars_uppercase=false
vars_lowercase=false
vars_prefix=_APP_
vars_type=global
default=irrelevant
---
---

Should result with the following variables

_APP_PERSON_NAME="Willy"
_APP_AGE="99"

I need to estimate the effort, though I don't think it's a big deal. Would love to get some feed to see if this type of feature will enhance your experience with bargs.

[ENHANCEMENT] #!/usr/bin/env bash instead of #!/bin/bash to support Mac's users with old default shell

Description
For many Mac users, the #!/bin/bash refer to an old bash version
/bin/bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)

Most of them have a newer version installed , but the direct call to #!/bin/bash will resolve the old version
in such cases , executing line like "declare -A _FOO_BAR" will not work( -A not support on bash v3)

Possible solution
Like describe in this post , calling #!/usr/bin/env is the suggested way to support different systems as Symlink requires to configure the Mac's SIP which is not so fun I guess.

I am interested in hearing about alternatives for Mac users

[BUG] "Empty argument" error when running a script with only a flag argument

Description of the bug
It seems that it isn't possible to invoke scripts running bargs and only supply flags as options. Doing this triggers an "[ERROR] Empty argument".

How To Reproduce
Steps to reproduce the behavior:

1. Clone the repo
2. Edit bargs_vars to only keep the --happy flag and remove all other options except the final bargs at the bottom
3. For completeness, edit example.sh to remove lines referencing the other vars besides $happy, although the script would die before it hits the echo
4. Run bash example.sh --happy - See the Empty argument error

Expected behavior
I would expect that I can invoke a script with only specifying a flag, e.g. bash myscript.sh --verbose - if no other options are specified or otherwise required.

Additional context
Is there maybe an issue with ordering or priority of logic between lines 195 and 215 of bargs.sh? Like I think the lines checking if [[ -n ${arg_dict[flag]} ]] need to be hoisted up and checked alongside a [[ -z $value ]] check.

I'm also not entirely sure why this works as long as other options are specified, though.
For instance, the supplied unit test works, specifying age, gender, and password options and then also having a --happy and a -ci flag properly send their values along.