Re: [PATCH] tools: fix oom setting of xenstored

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH] tools: fix oom setting of xenstored"):
> On 19.10.2021 09:31, Juergen Gross wrote:
> > I don't think set -e would have a negative effect on above line. The
> > bash man-page tells me that:
> > 
> >    The shell does not exit if the command that fails is part of the
> >    command list immediately following a while or until keyword, part of
> >    the test following the if, ...
> > 
> > And I believe that "[ ... ]" is treated like an "if".
> 
> I don't think so - "[ ... ]" is an equivalent of "test ...", i.e.
> unrelated to whether that's an operand of "if". The question is
> what effect && has, i.e. the behavior is due to what you've
> hidden by using ... in your quotation: "..., and is not a part of
> an AND or OR list, ...".

"[ ... ]" is precisely equivalent to "test ...".  But neither of these
is eqivalent to an "if".  When the docs say "part of the test
following the if" they are using the word "test" informally.

> I think I recall constructs like the one you use not working with
> "set -e" on at least some bash versions, though. Apparently this
> was due to a bash bug then (or I'm misremembering, but that's not
> overly likely since some of my long used scripts specifically
> avoid using && in such situations).

I agree that we should avoid this && construct.  Can we not just use
conditional assignment of a default value or an if statement ?

> >    ( set -e; [ -z "" ] && xx=okay; echo $xx; )
> > 
> > This will print "okay", so bash didn't exit.
> 
> Of course, because the left side of && succeeds. You'd need
> 
>    ( set -e; [ -z "xxx" ] && xx=okay; echo xx=$xx; )
> 
> and observe "xx=" getting printed. Which indeed I do observe on
> the one bash version I've tried to double check. But that one's
> surely newer than what I think I saw such problems on.

I think this particular && and || usage is not an idiomatic way of
spelling what would normally be a conditional in shell.

I think
  try_this || try_that
is fine but
  variable_nonempty || variable=value
is strange.

I would use ${param:=default_setting} or ${param:-default}
(or perhaps the colon-less variants).

Ian.