0
while getopts a:b:c: flag
do
   case "${flag}" in
        a) username=${OPTARG};;
        b) password=${OPTARG};;
        c) var1=${OPTARG};;
    esac
done
echo "Checking"
if [[ 'echo "$OPTARG" | grep -Eq ^\\-.+$' != 0 ]];
then
    echo "$0: option requires an argument -- ${OPT}"
    exit 1
fi

In case I am using one of the flags without any argument ./test.sh -a testarg -c

I am getting the output like that:

./test.sh: option requires an argument -- c
Checking
./test.sh: option requires an argument --

As you can see the output is quite strange instead of just one error message. I have added a Checking message to show that it appears in between. How to check in the correct way if the flag has been entered without any argument and stop the script

or at least in case of using flag -c without any argument to make variable var1=true but looks like bash can't support that.

Skuld
  • 13
  • 2
  • The string `'echo "$OPTARG" | grep -Eq ^\\-.+$'` will never be identical to the string `0`. – Charles Duffy Mar 25 '22 at 01:54
  • ...and if you changed it to `[[ $(echo "$OPTARG" | grep -Eq '^\\-.+$') = 0 ]]`, it would still always be false, because `grep -q` has no output, so it can't ever output `0`. – Charles Duffy Mar 25 '22 at 01:55
  • If you want to check if the _exit status_ is 0, that's just `if echo "$OPTARG" | grep -Eq '^\\-.+$'; then ...` -- you don't need `[[` at all. – Charles Duffy Mar 25 '22 at 01:56
  • Granted, none of those bugs are on-point for the question you're asking, because the piece of your code that would be emitting this error would be `getopts`. I strongly advise against using it at all; see [BashFAQ #35](https://mywiki.wooledge.org/BashFAQ/035) for a discussion of good practices in command-line parsing. – Charles Duffy Mar 25 '22 at 01:57
  • ...that said, you're telling getopts to handle flags `u`, `p`, and `c`, but then your code only checks for flags `a`, `b` and `c`. If you want to tell getopts to handle `-a`, you need to include `a` in the string you pass it describing which arguments are legal. – Charles Duffy Mar 25 '22 at 01:58
  • BTW, you're making assumptions about output ordering that aren't necessarily called for. If stdout is buffered, stderr can be printed first even if the thing that causes the error happens after the output tries to print. (Whether that actually happens depends on runtime details you aren't describing in the question; in particular, stdout is line-buffered by default when output is to a TTY, but fully buffered when output is to a file or pipeline). _In general_, you should send all messages meant for human readers to stderr instead of stdout. – Charles Duffy Mar 25 '22 at 02:00
  • The other thing I'd ask for before reopening this question is a [mre] -- code someone else can run _without changes_ to see the same problem. – Charles Duffy Mar 25 '22 at 02:02
  • See https://ideone.com/iPuVFq making it clear what's happening. The "illegal option -- a" is written to stderr by `getopts` because you aren't telling it that `a` is legal. – Charles Duffy Mar 25 '22 at 02:03
  • my mistake i have corrected the first line to `while getopts a:b:c: flag` – Skuld Mar 25 '22 at 03:39
  • Error messages belong on stderr: `echo ... >&2` – William Pursell Mar 25 '22 at 04:00

0 Answers0