Drop `$(...)` if you meant to run the command

Problem

Writing `$(some_command args)` as a bare statement runs `some_command`, captures its stdout into the substitution, and then does nothing with that captured value — Bash tries to execute the resulting string as a command (which usually fails or does something unintended) rather than running `some_command` directly for its side effects. This typically happens when someone copies a snippet intended for variable assignment (`x=$(cmd)`) but drops the assignment, or misremembers that command substitution is needed to "run" a command.

Bad

$(rm -f "$tmpfile")   # runs rm, then tries to execute rm's (empty) output

Good

rm -f "$tmpfile"

Explanation

Command substitution exists to capture output as a string for later use, not to invoke a command. If you just want to run a command for its effect (or its exit status), call it directly with no `$(...)` wrapper. Reserve `$(...)` for cases where you actually assign or use the captured output.

Related

SC2005

SC2116

SC2046

When It Matters

Writing $(command) as a statement runs the command, captures its output, and then tries to execute that output as another command. When the output is a filename or a sentence you get "command not found" naming a fragment of the output, which is baffling until you notice the substitution. It is almost always a stray dollar sign left behind while editing a line that used to be an assignment.

Second Example

Exceptions

Tools designed to print shell code to be evaluated are the legitimate case, and they should use eval rather than a bare substitution. Everything else is an editing mistake.

Faq