On 10.10.2016 20:43, Eric Blake wrote:
On 10/10/2016 11:48 AM, Stefan Bader wrote:
>> I did not hear about that before. But revisiting things again I think what
>> happened is that the Xen patch which I had done before (but at that time forgot
>> to submit upstream) was adding quotes there because without, the grep does not
>> work. Back then I did not realize this broke the shutdown as that also had
>> quotes around the list. All the other users of the list are ok because they wrap
>> the processing into for ... loops and for those newline or space does not
matter.
>
> I think the surprising part is that the calls to virsh like:
>
> list=$(virsh ... list)
>
> seem to retain the newline seperator despite having no quotes. Only when using
> echo with the unquoted variable seems to do that. That is with dash as sh at least.
That's true for ALL shells. Word splitting does NOT happen during
variable assignment. list=$() is _strictly_ equivalent to list="$()",
no matter the shell.
Funny that with all those years working with shells I never memorized that as a
fact. :) Guess it was enough to adhere to the good habit and just use "$()" all
the time.
So just as a wrap up, the first patch ends up not being a fix in the strict
sense as before the second patch word splitting would happen in the list_guest
function. Luckily it neither breaks anything on its own as the result is the
same whether list was already split or not. Somehow I subconsciously reordered
it to come before the dom0 patch which I had done here before (without noticing
that the list file is then broken for more than one guest to shutdown). Somehow
the big part of adding the grep in the dom0 patch made me miss the additional
quotes around the variable. In hindsight maybe the better way would have been to
add a new line which filters the dom0 uid and reassigns the result to list and
keep the echo line unmodified. But then, the end result now should be working
and robust enough...
-Stefan
It's just that there are so many other places where $() and "$()" behave
differently that it's (usually) a good habit to always use "", rather
than learning the rules on when you NEED them, vs. telling the special
cases when you DON'T want them apart from the cases where they are optional.