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-*
The only reason to do this is to ensure uniformity with the other
options, that work like this, i.e. ConditionOSRelease= or
ConditionSecurity=.
This is a compatibility break, but a minor one, given that string
comparison and version comparison is mostly the same for equality and
inequality.
This ensures that "=" and "!=" are now interpreted as literal string
compares, and "==" and "<>" are for version compares.
This is not a compat break, since the SMBIOS stuff has not been included
in any release yet.
Main reason to do this, is to be systematic with the other conditions
that check for text stuff.
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.
Often I end up debugging a problem on a system, and I
do e.g. `journalctl --grep=failed|error`. The use of the term
"failed" for condition checks adds a *lot* of unnecessary noise into
this.
Now, I know this regexp search isn't precise, but it has proven
to be useful to me.
I think "failed" is too strong of a term as a baseline, and also
just stands out to e.g. humans watching their servers boot or
whatever.
The term "met condition" is fairly widely used, e.g.
https://stackoverflow.com/questions/63751794/what-does-the-condition-is-met-exactly-mean-in-programming-languages
Use that instead.
Unfortunately, hex output can only be produced with unsigned types. Some
cases can be fixed by producing the correct type, but a few simply have
to be cast. At least casting makes it explicit.
Lennart Poettering
Yu Watanabe
Antonio Alvarez Feijoo
dependabot[bot]
Colin Walters
Frantisek Sumsal
Jan Janssen
Luca Boccassi
Swapnil Devesh