-4

This idea came to me with recent updates to Visual Studio Code, in which I usually shellcheck my code automatically as well. This is what I see, so you can get the idea:

enter image description here

This question is very simple indeed for those who can test in many shells, I only have Bash and Dash installed:

Is it possible for any shell to interpret a string with decimal point as a number (int, float)?

Thank you for your time.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255

2 Answers2

3
var=value

If we only look at the main Unix shell families, is scalar variable assignment in Bourne-like shells, variable assignment in rc-like shells (all variables being lists, and here a list with one value), an error in fish and running the var=value command in csh-like shells (more on that at Spaces in variable assignments in shell scripts).

In those where that's an assignment, for the value of that variable to be attempted to be treated as a number, you'd need $var (or var sometimes in Korn-like shells) to be used in contexts that expect a number or arithmetic expressions.

As in (not all applying to all shells)

arr[var]=foo
printf '%g\n' "$var"
printf '%d\n' var
(( var++ ))
echo "$(( var ))"
[[ var -gt 2 ]]
shift var
echo "$var + 1" | bc
export var; awk '{print ENVIRON["var"] + 1}'

In Korn-like shells including ksh, bash, and zsh, if the variable has been declared with typeset -i var, or same with -E, -F or -X, or integer var or float var (not in bash/pdksh for the floating-point ones), then it is interpreted as a number upon assignment.

192.168.0.40 is neither a valid integer nor floating point number in any base or locale though. 192.168 is a valid floating point number in many contexts and may be a valid integer in locales where the thousand separator is ..

192.168.123.123 (with always 3 digits per group, other than the first) would be the same as 192168123123 in locales where . is the thousand separator so could be accepted as such in contexts that expect a number and where locale thousand separators are accepted.

I know of only ksh93's arithmetic expressions where that's the case. For instance:

$ LC_ALL=it_IT.UTF-8 var=192.168.123.123 ksh93 -c 'printf "%e\n" var'
1,921681e+11
$ LC_ALL=it_IT.UTF-8 ksh93 -c 'echo "$((192.168.123.123 * 2))"'
384336246246
$ LC_ALL=it_IT.UTF-8 ksh -c 'integer var; var=192.168.123.123; echo "$var"'
192168123123

Here in an Italian locale where comma is the decimal radix character and period the thousand separator.

But in any case as long as you don't explicitly ask the contents of the variable to be interpreted as a number like in all those cases above, it won't be interpreted as a number, that editor's syntax highlighter is just being misleading, a shell is primarily a tool to run commands, commands being lists of string arguments¹, so shell variables by default typically just contain strings or lists of strings and it's up to the commands that the shells execute to interpret those strings as numbers, file names, user names, IP addresses or whatever they like.


¹ sequences of 0 or more bytes other than 0 for those that are executed by way of the execve() system call as its second argv[] argument is an array of pointers to C (NUL-delimited) strings.

ilkkachu
  • 138,973
0

I only have Bash and Dash installed.

From the context given it's not possible to determine if these variables have a type specified, but:

bash-5.2$ declare -i n
bash-5.2$ n=192.168.0.40
bash: 192.168.0.40: syntax error: invalid arithmetic operator (error token is ".168.0.40")
muru
  • 72,889
  • 1
    (bash and dash being some of the very few shells that still don't have floating point arithmetic support; the OP was asking what the situation was for other shells he didn't have access to) – Stéphane Chazelas Jun 27 '23 at 06:21
  • @StéphaneChazelas I interpreted it differently - to me, it reads like: "I only have bash and dash installed, and these assignments work fine in them, so why is this syntax highlighting saying any different? Is it some other shell that's broken?" ... and turns out it can be a problem in bash as well. – muru Jun 27 '23 at 06:31