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...

> 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.

Attachment: signature.asc
Description: OpenPGP digital signature

libvir-list mailing list

Reply via email to