'==' used inside a single-bracket [ ] test
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 2 points from that category, once per scan, no matter how many places it turns up.
What it detects
== inside a single [ ... ] test is a bash extension to the POSIX test builtin; under a strictly POSIX /bin/sh (dash, on Debian/Ubuntu that's the actual /bin/sh) it is a syntax error or silently does the wrong thing. Use = inside [ ... ] for portability, or switch to bash's [[ ... ]] where == is well-defined.
Why it matters
== inside a single [ ... ] test is a bash extension to the POSIX test builtin, not part of the POSIX standard itself. Under a strictly POSIX /bin/sh, dash on Debian/Ubuntu-derived systems is the actual /bin/sh, this either throws a syntax error or is not guaranteed to behave the same way, so a script that works when the author tests it under bash can fail wherever it is actually deployed with a different /bin/sh.
How to fix it
Use = instead of == inside a single [ ... ] test; they mean the same thing there and = is the portable, POSIX-defined form. If the script is bash-only anyway (uses arrays, [[ ]], or other bash-only features elsewhere), switch the test to bash's own [[ ... ]], where == is well-defined and also supports pattern matching.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo