| hindenburg |
| Konsole |
The env var is exported as a numeric string (by removing the dots from
the version string), this has the benefit of making it simpler to compare
the version in shell arithmetic expressions.
This should help programms like neovim check if konsole has support
for terminal capabilities (e.g. DECSCUSR) by using a condition that
checks the konsole version. See also:
https://github.com/neovim/neovim/issues/8300
CCBUG: 347323
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Thanks, have they expressed that this is what they'd like to check for? Do any other terminals export their versions?
Both XTERM and VTE export XTERM_VERSION AND VTE_VERSION respectivley; and there's this commit where there's a condition based on vte_version:
https://github.com/neovim/neovim/commit/809420233c591c81aede48679a42fce90e75bb6f#diff-3ac88981a139ac0eee448a6bd19c7569R1433
Ok I should have explained better; do they want XX.YY.ZZ or something else? I notice xterm and vte just use a # (without .)
They didn't actually ask for this change (the upstream issue I opened to notify upstream of adding support for DECSCUSR was closed as there's no easy way for upstream to test the version of the konsole terminal they're running under).
XTerm doesn't seem to have point releases, so version (patch) numbers don't have dots at all.
As you indicated, VTE exports the version as a numeric string without the . ; this seems reasonable as this makes much easier to use the version env var in an arithmetic expression in the shell (bash's arithmetic operators only support comparing between integers).
Even bash has BASH_VERSINFO which is an array, for example on my setup:
BASH_VERSINFO=([0]="4" [1]="4" [2]="19" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu")
So it does make sense to export the konsole version as e.g.:
180770
if you agree I'll update the diff.
Use a numeric string for the version env var (by removing the dots from the version string).