Use FOREACH_ELEMENT where possible. Generated with this command,
and checked manually:
git grep -l 'FOREACH_ARRAY.*ELEMENTSOF' | \
xargs sed -ri 's/FOREACH_ARRAY\((.*), (.*), (ELEMENTSOF.*)\)/FOREACH_ELEMENT(\1, \2)/'
So this is a bit of a bikeshedding thing. But I think we should do this
nonetheless, before this is released.
Playing around with the glob matches I realized that "=$" is really hard
to grep for, since in shell code it's an often seen construct. Also,
when reading code I often found myself thinking first that the "$"
belongs to the rvalue instead of the operator, in a variable expansion
scheme.
If we move the $ character to the left hand, I think we are on the safer
side, since usually lvalues are much more restricted in character sets
than rvalues (at least most programming languages do enforce limits on
the character set for identifiers).
It makes it much easier to grep for the new operator, and easier to read
too. Example:
before:
ConditionOSRelease=ID=$fedora-*
after:
ConditionOSRelease=ID$=fedora-*
These two operators always indicate ordering comparisons, as opposed to
"=" and "!=" which depending on context mean literal string compares.
This is useful for ConditionOSRelease= for example, as this means
there's now always a way to do version compares.
Let's change the lookup table to contain pairs of operator/strings,
instead of being indexed by operator.
The table isn't dense anymore, and this allows us to add alias strings
sooner or later.
None of our other fnmatch() calls make use of this, and the concept was
new to me at least. Given that this is only used for the recently added
SMBIOS field matches (and is not included in any release) let's disable
"extended" matches for now. We can certainly revisit this, and enable it
later if there is real demand, but if we do, we should probably add that
all over the place, not just for smbios matches.
Let's move the operator enum into its own .c/.h file, so that we can
reuse it elsewhere, in particular systemd-analyze's compare-versions
logic.
Let's rename the concept CompareOperator, since it is nowadays
genericlaly about both order *and* fnmatch comparisons, hence just
naming it "order" is misleading.
Matteo Croce
Mike Yuan
Yu Watanabe
Lennart Poettering