Return to Answer

##Use the simplest tool for the job Although awk can pick out fields from a line, that's the sole purpose of cut, and I think it's clearer that that's all you're doing if you write like

Note that this is now a stricter test - it won't be fooled by a value containing applnId, for instance; it recognises only a key of exactly applnId.

##Be more specific when reporting errors This test doesn't tell the user much:

I'd omit the last case, though - I'm not a fan of overly chatty programs.

(This is a partial review. I'll complete it when Real Life gives me some more time...}

Related to this is ##Keep the error handling close by The program has more than one structure that looks like

if some_test
then
    ...
    lots
    ...
    of
    ...
    code
    ...
    here
    ...
    if second_test
    then
        ....
        more
        code
        ...
    else
        echo "INNER FAIL"
    fi
else
    echo "FAIL"
fi

This can make it harder to relate the else clause to the correct if. My usual approach to this is to define a die function:

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

Then the structure above becomes more linear and less indented:

some_test || die "FAIL"
...
lots
...
of
...
code
...
here
...
second_test || die "INNER FAIL"
....
more
code
...

This might not work for you if you want to report more than one problem per run, but it's certainly something to consider and possibly adapt for your purposes.

##Use the simplest tool for the job Although awk can pick out fields from a line, that's the sole purpose of cut, and I think it's clearer that that's all you're doing if you write like

Note that this is now a stricter test - it won't be fooled by a value containing applnId, for instance; it recognises only a key of exactly applnId.

Actually, since you have asked for JSON output, it's easier and more reliable to use jq than pure Bash to parse it:

applnId=$(jq -r applnId <<<"$exactserverdetails")

Similarly, to test the environment name:

test "$(jq -r environment_Name <<<"$exactserverdetails")" = Dev \
    || die "Environment name is not 'Dev'"

##Be more specific when reporting errors This test doesn't tell the user much:

I'd omit the last case, though - I'm not a fan of overly chatty programs.

##Be more specific when reporting errors This test doesn't tell the user much:

Conversely, if you use awk, use it fully - the applnId pipeline (sed|grep|awk) can be done with a single awk invocation:

awk -F: 'BEGIN { RS = "," } $1 == "applnId" {print $2}'

Note that this is now a stricter test - it won't be fooled by a value containing applnId, for instance; it recognises only a key of exactly applnId.

##Be more specific when reporting errors This test doesn't tell the user much:

token=$(echo $fulltoken | cut -d: -f8 | cut -d, -f1 | tr -d \")

token=$(echo "$fulltoken" | cut -d: -f8 | cut -d, -f1 | tr -d \")

##Be more specific when reporting errors This test doesn't tell the user much:

    if [ -n $appInId ] && [ $appInId != "null" ]
    then
        echo "PASS"
    else
        echo "FAIL"
    fi

Instead, I'd write:

    case "${appInId-}" in
      '') echo "No applnId" >&2; exit 2;;
      null) echo "applnId is 'null'" >&2; exit 2;;
      *) echo "applnId is valid";; # (if you must)
    esac

I'd omit the last case, though - I'm not a fan of overly chatty programs.