Expanded variable as argument of another command via concatenation in Bash

Question

Imagine I want to call some command some-command via $() with an argument stored in another variable argument, the latter containing space.

1. With my current understanding, the fact that result="$(some-command $argument)" (e.g. expansion) leads to passing two arguments is as expected.

2. Question part: why does the result="$(some-command "$argument")" (e.g. concatenation) lead to the desired result of passing one single argument?

More details:

./some-command:

#!/usr/bin/env bash
echo "Arg 1: $1"
echo "Arg 2: $2"

./test-script:

#!/usr/bin/env bash

export PATH="`pwd -P`:$PATH"

argument="one two"

echo "Calling with expansion"
res="$(some-command $argument)"
echo $res

echo "Calling with concatenation"
res="$(some-command "$argument")"
echo $res

Calling test-script leads to the following output:

Calling with expansion
Arg 1: one Arg 2: two
Calling with concatenation
Arg 1: one two Arg 2:

I seem to not grasp when smth is expanded / evaluated and how the expanded variables are grouped into arguments passed to scripts.

Thank you!

P.S. Bonus curiosity is why result="$(some-command \"$argument\")" does not work at all.

Answer 1

That's how quoting and expansions work in bash. In fact, double quotes after = are not needed, as word-splitting is not performed, so

result=$(some-command "$argument")

should work the same way.

There's no "concatenation" going on. Bash treats the string inside $() as a command and runs all the expansions on it before running it.

So, what happens with some-command "$argument"? First, the parameter expansion expands $argument into a string containing spaces. When word-splitting happens, it notes the string was enclosed in double quotes, so it keeps it as a single string.