Useless echo — assign the value directly

Problem

Wrapping a variable in `$(echo …)` forks a subshell for no reason — the shell can assign one variable to another directly. The pattern usually appears when someone wanted to trim whitespace or strip quotes but reached for echo instead of parameter expansion.

Bad

name=$(echo "$first")
trimmed=$(echo $raw)   # also breaks on internal whitespace

Good

name=$first
# To trim, use parameter expansion:
trimmed=${raw## }
trimmed=${trimmed%% }

Explanation

If you actually wanted word splitting (rare), use `read -r` or explicit IFS handling instead of relying on unquoted command substitution.

When It Matters

var=$(echo "$other") forks a subshell and a process to produce a value you already had. Beyond the waste, the round trip through echo mangles the data: trailing newlines are stripped, leading and trailing whitespace can survive in surprising ways, and a value that begins with a dash may be interpreted as an option by some echo implementations. It shows up most often as a leftover from debugging, where an echo was added to inspect a value and never removed once the assignment was wrapped around it.

Second Example

Exceptions

echo inside a command substitution is legitimate when you are using it to feed a pipeline or to normalise whitespace deliberately, for example x=$(echo $unquoted) to collapse runs of spaces. That is a real idiom, but it is worth a comment, because the behaviour depends on the deliberate lack of quotes.

Faq