"s" * 0 - openSUSE Bash completion breaks Bash functionality

English Programming/Scripting
1

Make the test:


$ a=s
$ echo $(($a * 0))
bash: /etc/bash_completion.d/zypper.sh: syntax error: operand expected (error token is "/etc/bash_completion.d/zypper.sh")

$ a=u
$ echo $(($a * 0))
0

$ echo "#! /bin/bash" > ~/.bash.expert
$ bash
$ a=s
$ echo $(($a * 0))
0

Conclusion: You have to be an expert to multiply “s” by 0.

Non shell programmers might say that Bash doesn’t have a clean way to check if a variable is an integer and that multiplying a string by 0 for the purpose of testing is just a hack. There is another way to check, but it’s boring and looks ugly:

if  $a != [0-9]* ]] ; then ...

That will work under openSUSE as well, even if you’re not an expert (don’t have the file ~/.bash.expert- which can do nothing, as in my example) and don’t use bash completion - that nobody knows about anyway. But what about running scripts which use this hack?

I didn’t know if I could call it a bug, so I asked my wife (I’m not Colombo but she’s a good programmer). She said, it doesn’t break Bash functionality, because it’s not a functionality, just an expected behaviour. If many Bash programmers use $(($a * 0)) to check if a variable is a non zero integer (and not a string or 0), one could say that it breaks Bash expected behaviour. If you’re the only one (meaning me), nobody will feel sorry for you (meaning me again). lol!

Anyway, whether the test is elegant or not, the error originates in /etc/bash_completion.d/zypper.sh.

2

So this is strange stuff and shows to go you that you should never make something equal s unless you know what s is equal to. So, you can do this:

s=u ; a=s ; echo $(($a * 0))

and then get a:

0

and for some reason, if you open up a new console and type:

echo $s

you get the answer of:

/etc/bash_completion.d/zypper.sh

Which is why doing a :

a=s ; echo $(($a * 0))

gives the error of:

bash: /etc/bash_completion.d/zypper.sh: syntax error: operand expected (error token is "/etc/bash_completion.d/zypper.sh")

But why is s equal to something when you first open up a terminal session and is the script /etc/bash_completion.d/zypper.sh to blame? I just don’t know the answer.

Thank You,

3

Because s ends up in the environment with the value “/etc/bash_completion.d/zypper.sh”

$set | grep "^s="
s=/etc/bash_completion.s/zypper.sh

$ grep 's="' /etc/bash_completion.d/zypper.sh
        s="${COMP_WORDBREAKS// }"
        s="${s//        }"
        s="${s//\{\}()\\]]}"
        s="${s}         (){}]"

Thus in a new terminal, you could do

unset s ; a=s ; echo $(($a * 0))

And it would give you 0.

But I don’t understand that:

The first s in a variable. The second s is a string (you’re assigning “s” and not “$s”) . I don’t get the trick. :frowning:
Actually, I cannot explain my unset example either. Those two “s” don’t describe the same thing eihter.

It looks like the mathematic expansion performs indirect expansion, so “$a” in the following expression

a=s ; echo $(($a * 0))

is the same as ${!a}, in which case it doesn’t match the string s but the value of the variable represented by this string.

Well, it doesn’t matter in a script. I should have started with that. The bash completion only works in interactive shells.
It was just a funny post … for a change. lol!

4

Well I am not sure I would describe this as being funny but more being strange I guess. And, at least in a bash script, I set values up before I tried to use them. Also, perhaps, your knowledge of bash makes it more funny that the rest of us can get a handle of. So to that I say, have another cup of coffee and go on to the next message.

Thank You,