Ran into a minor error where I was testing some dec<->hex conversion values, and later testing the display of a unicode char.
Problem happened when I re-used a var that had earlier had the integer property set on the variable. declare -i a=123 ... then later a="▯" -bash: ▯: syntax error: operand expected (error token is "▯") (u+25AF) (the character didn't have a font for it, so displayed as a square) 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'). But if I try: a="z", I get the syntax error again(**) 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 So why does something with the integer attrib set work somewhat 'ok' (if '0' is what you expect)...oh... (**) - because in coming up with test cases, I had tried assigning that 'u+25af' (▯) to 'z', oh ...just weird. if the target has the int flag set, and what you assign is not an integer, then you might get '0' in 'a' and no error, or you might get a syntax error... Um... This behavior is a bit confusing... It would really be better if it could say what it was expecting, like printf. ?? I guess it's based on whether or not what you are assigning could be a variable name -- but that sorta dovetails into something else I'd been thinking about: being able to use more unicode characters in var and function names, like: $☃="snowman" hmmm....Well, double the "want"/"need" for better error messages, first. Then might be nice to allow more unicode class-"alnum" into the varname-composition class?
