[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Wanted: better(more specific) error msgs?

From: L A Walsh
Subject: Wanted: better(more specific) error msgs?
Date: Sat, 25 May 2019 18:21:27 -0700
User-agent: Thunderbird

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
-bash: ▯: syntax error: operand expected (error token is "▯")

(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:


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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]