Return to Answer

$ a='x[1$(uname>&2)]' bash -c '[ "$a" -eq "$b" ]' bash: line 0: [: x[1$(uname>&2)]: integer expression expected</pre> 

$ a='x[1$(uname>&2)]' bash -c '[ "$a" -eq "$b" ]' bash: line 0: [: x[1$(uname>&2)]: integer expression expected 

• http://www.zsh.org/mla/workers/2014/msg01041.html (where Oliver Kiddle brought the x[0$(...)] issue to our attention).
• http://thread.gmane.org/gmane.comp.standards.posix.austin.general/9971
• http://thread.gmane.org/gmane.comp.shells.bash.bugs/22737 for another mis-design potentially leading to code injection in bash.
• Security implications of forgetting to quote a variable in bash/POSIX shells where that and leaving a variable unquoted can aggravate each other.

• http://www.zsh.org/mla/workers/2014/msg01041.html (where Oliver Kiddle brought the x[0$(...)] issue to our attention).
• http://thread.gmane.org/gmane.comp.standards.posix.austin.general/9971 (lynx news://news.gmane.io/gmane.comp.standards.posix.austin.general/9971 now that gmane's web interface has been discontinued).
• https://lists.gnu.org/archive/html/bug-bash/2014-12/msg00028.html for another mis-design potentially leading to code injection in bash.
• Security implications of forgetting to quote a variable in bash/POSIX shells where that and leaving a variable unquoted can aggravate each other.

Beware that [0-9] and [[:digit:]] in some locales matches more than 0123456789 so should be avoid for any form of input validation/sanitisation.

Beware that [0-9] and [[:digit:]] in some locales matches more than 0123456789 so should be avoided for any form of input validation/sanitisation.