Design: `onyo get --match` should be able to do `>`/`<`

[aqw]

This is split out from #361.

onyo get should be able to do the following comparisons:

• <
• >
• <=
• >=

It should use natsort's sorting (which uses the locales COLLATE). This also matches the behavior added to the 2024 POSIX spec.

The question is the CLI syntax itself:

onyo get --match cpu.cores<4

Shell interprets 3/4 of the above symbols as redirection, so they have to be quoted:

onyo get --match 'cpu.cores<4'

The above syntax no longer always has = as a delimiter. Which makes determining what we're telling onyo to do more complicated. = is already implicitly disallowed in the keyname (see #718), so the weirdest we can get is:

• weird<key=weird>=value

I propose extending the protected characters list in the keyname to include < and > (for a total of ., =, <, and >.)

At that point, the weirdest onyo will see is:

• key><weird>=<value

I propose the following logic:

• find the first >, <, or =
  • if =, check if the preceding character is < or >
  • this determines the comparison mode
• split and/or trim accordingly

Note: I strongly prefer suffixing the equals sign (e.g. <= and >=) rather than prefixing.

• everyone does it this way
• it matches how one says it in english "greater than or equal"
• I am generally against limiting characters in the value, but am ok with limiting characters in the key to reduce complexity.
• reduce ambiguity in the situation key=<unset>

Barely related, if onyo is passed a tag (such as <nope>) that is not an onyo-reserved tag (such as <unset>, <list>, etc), should onyo warn? This would only be the case if the entire value is a tag, not just a substring. If so, an issue should probably be opened for that.

[bpoldrack]

Barely related, if onyo is passed a tag (such as ) that is not an onyo-reserved tag (such as , , etc), should onyo warn? This would only be the case if the entire value is a tag, not just a substring. If so, an issue should probably be opened for that.

I already proposed to reserve anything enclosed in < and > to be special (labels and variables). So, I think while no characters should be strictly forbidden in values, they must not start with < and end with >. So, that wouldn't pass validation and we error when we encounter such a thing that is unknown.

[aqw]

I already proposed to reserve anything enclosed in < and > to be special (labels and variables). So, I think while no characters should be strictly forbidden in values, they must not start with < and end with >.

I am generally ok with this, but it means that values cannot contain XML/HTML.

The following would run afoul of the proposed rule:

html: <p>Some HTML content.</p>

I think what we're actually imagining is a more explicit regex: ^<[^<>]+>$

• starts with < and ends with >
• does not contain < or > anywhere else