Looking at

My guess is that the intended behavior was to terminate program execution and print out an error message. However, in most cases sanitize_input will be used in a sub-shell such as

This will terminate the sub-shell with exit code 1, but unless checked in the super-shell, will continue normal execution, which is what's happening here.

Suggestions to resolve the bug:

• When reporting an error, direct it at stderr and not stdout (which is why we have it 😉 ), eg:

  echo "Invalid argument: $arg" >&2
  exit 1
  

• Check for sub-shell exit code:

  args=$(sanitize_input "$@") || exit 1
  

• We can also leverage set -e option, which will automatically abort script execution on error.

• To add consistency and reduce boiler-plate we could introduce commands such as:

  error() { echo "$@" >&2; }
  die() { error "$@"; exit 1; }
  

  Then the above code becomes something like:

  sanitize_input() {
      ...
          die "Invalid argument: $arg"
      ...
  }

  and

  args=$(sanitize_input "$@") || die

And, obviously, sanitize_input should allow dashes in the input.

@dimitry-ishenko Sanitise input contribution was aimed primarily at removing escape sequences.
This is one of the placeholder implementations that is incomplete and needs refinement or replacement. Another example you are familiar with is process_input.

This has been a place for expanding and learning: If a may ask :) Are you saying that while the implementation is flawed (BUG), the concept is not, and sanitize_input should handle input validation more comprehensively rather than be removed?

For later implementation and though.
If we validate, should we not include a manner to use the database to actually verify inputs?

Are you saying that while the implementation is flawed (BUG), the concept is not, and sanitize_input should handle input validation more comprehensively rather than be removed?

It's hard to tell without knowing the original intent, but I would say it should be removed... I am not a security specialist, but I don't see what problem it's trying to solve... Is there a case of using an escape sequence to compromise the system?

Or, if there is a valid need for it, then maybe it can be modified to use a blacklist to detect escape char in the input instead.

The intent was precaution more than anything for when armbian-config was not strictly an admin tool as it is now.

Maybe it should be removed for now, and if the need arises later, it can be resurrected. Just my 2 cents.