Globing in config scripts

I’m trying to limit a parameter in a mender-configure script to an integer range 1000-60000. Using example patterns provided by Mender I have something like this (edited for brevity):

shopt -s extglob

case "$desired_param" in
    +([[:digit:]]) )
	    if (($desired_param >= 1000 && $desired_param <= 60000)); then
		configuration=$(jq -n --arg interval $desired_param '{"timeUpdateInterval": $interval | tonumber}')
		echo $configuration
	    else
		echo "$desired_param is out of range for $i"
		exit 0
	    fi
	    ;;
    null)
        echo "$i value was not provided, default configuration will be used" ;;
    *)
        echo "$desired_param is not a valid value for $i"
        exit 0
        ;;
esac

If I run this directly from a shell, it works as expected. If I run a script, that calls this script from a shell it works. But if mender-configure-module calls it, it throws a syntax error on the opening paren of the pattern ’ +([[:digit:]])’

Can anyone help me understand why this might be happening?

Hi @dallas.posey, my best guess is that Mender is directly calling using /bin/sh rather than bash. I think the syntax it is complaining about is a bashism. You may be able to just change the shebang to explicitly call bash. Alternatively modify your script to remove the bashisms. There are tools and blog posts to help; just google for “check bashism”.

HTH,

Drew

Actually the problem was that extended globbing was not enabled in the production script. Just needed to add the shopt command. The mender-configure-module script is Bourne (which does grok extended globbing and the shopt directive) but the shopt directive was not specified there or the subordinate (#!/bin/bash) script either. Should not have missed that … guess I’m getting old, overconfident, lazy or a combination thereof.

I will say this was a useful exercise though. While spelunking the problem, I found that both /bin/sh and /bin/bash link to /bin/bash.bash. I’ve never noticed this before on other systems. This leads me to believe that Bash will do both Bourne and Bourne Again in the same executable and maybe figures out which based on argv[0]? Anyway … thought that was interesting.