Re: Wanted: better(more specific) error msgs?

[Greg Wooledge]

On Sat, May 25, 2019 at 06:21:27PM -0700, L A Walsh wrote:
> Problem happened when I re-used a var that had earlier had the
> integer property set on the variable.
> 
> declare -i a=123

That's (part of) why I strongly recommend that nobody ever use that -i
flag.

> then later
> a="▯"
> -bash: ▯: syntax error: operand expected (error token is "▯")
> (u+25AF)

Sounds reasonable.

> I'm still not sure why it is giving a syntax error when
> a="t", for example doesn't (it puts a value of '0' in 'a').

Because the variable t is probably not set.

> But if I try:
> a="z", I get the syntax error again(**)

> (**) - because in coming up with test cases, I had tried
> assigning that 'u+25af' (▯) to 'z', oh ...just weird.

And that's why.  Remember, in a math context, bash variables undergo
recursive expansions.  Using declare -i forces *every* assignment to
this variable to operate in a math context instead of a string context.

> Ideally, I'd prefer to see something like printf
> prints out when it finds a non number for a decimal field:
> > printf "%d" "t"
> -bash: printf: t: invalid number

> It would really be better if it could say what it
> was expecting, like printf.

It told you what it expected: an "operand".

You're performing an assignment in a math context, so what it's expecting
is, ultimately, a valid integer expression.  Bash will recursively resolve
anything that looks like a variable name as another math expression,
defaulting to 0 for empty/unset expressions.

When the math parser runs into something like é that can't be a variable
name and can't be parsed as an integer expression, it throws a syntax
error.

wooledg:~$ let x=é
bash: let: x=é: syntax error: operand expected (error token is "é")
wooledg:~$ let x=%
bash: let: x=%: syntax error: operand expected (error token is "%")
wooledg:~$ let x=1+
bash: let: x=1+: syntax error: operand expected (error token is "+")

Looks like it just uses that one syntax error for all the cases.  Unwinding
the state within the math parser to try to give a more descriptive error
message is probably difficult.