Home | History | Annotate | Download | only in unit-tests

Lines Matching refs:condition

4 # the then-expression or the else-expression, depending on the condition.
14 # condition. In the below example it becomes:
20 # fine since the condition would be:
27 # expect+1: Bad condition
35 # Because of the early expansion, the whole condition evaluates to
38 # expect+1: Bad condition
44 # becomes the condition, in this case ' == ""', which is malformed because the
46 # expect+1: Bad condition
69 # expect+1: Bad condition
76 # If the "Bad condition" appears in a quoted string literal, the
78 # condition".
90 # condition should be detected as being malformed before any comparison is
91 # done since there is no well-formed comparison in the condition at all.
93 # expect+1: Bad condition
102 # this expansion is then taken as the condition. To force the
103 # expression in the condition to be evaluated at exactly the right point,
106 # the condition ends up as "${VAR} == value", just as intended.
128 # The tricky detail here is that the condition that looks so obvious in the
130 # This is because the condition is written in the place of the variable name
142 # the comparison operator, but only because this is a condition in the
155 # instead of just saying that the whole condition is bad.
167 # expect+2: Bad condition
170 # expect+2: Bad condition
184 # syntax error since the condition is completely blank.
185 # expect+2: Bad condition
190 # Since the condition of the '?:' modifier is expanded before being parsed and
266 # Since the condition is taken from the variable name of the expression, not
270 # alternative ways to bring a '$' into the condition.
272 # In an indirect condition using the ':U' modifier, each '$', ':' and
276 # In an indirect condition using a separate variable, each '$' must be
280 # condition parser does not see them.
317 # expect+4: Bad condition