>Can you point me to the specific part in the specification which would >indicate this is a bug vs >the standard?
The relevant material is on page 49 of the standard. You may find the standard here: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.416-199303-I!!PDF-E&type=items ``A parameter substring for values 38 or 48 may be divided by one or more separators (03/10) into parameter elements''... Due to the ``may'', it seems fair to interpret this as allowing either semicolons or colons to be used to separate the parameters. However, st only interprets such with the semicolons, which is a flaw. ``If the first parameter element has the value 2, 3, or 4, the second parameter element specifies a colour space identifier referring to a colour space definition in the document profile.'' The colour space identifier isn't discussed further in the standard, so it's reasonable to leave it at its default value. However, st and other terminals entirely ignore this parameter and interpret it as the third parameter and all others are shifted as well. >A reproducable small test program in shell would be nice also to compare to >other terminal emulators. Here is an example of a correct sequence to form a red, assuming 255 is a permitted value: CSI 38;2::255:0:0m You can express this with the following: printf '\x1b[38;2::255:0:0m' St and others require this incorrect form to be sent, instead (ignoring here that st doesn't properly parse with colons used): CSI 38;2:255:0:0m You can express this with the following: printf '\x1b[38;2:255:0:0m'
