Kurtis Rader

@rphaniram I cannot reproduce your problem. I should be able to do so given our current knowledge of the problem. However, I am not using rlogin since I do not...

Also, @rphaniram, please note that problems involving Unicode code points that are outside of the ASCII range of code points is quite common. There are many programs that do not...

### Answer for question 1 On my system: ``` $ ksh --version version sh (AT&T Research) 2020.0.0 ``` The "AJM" portion is no longer present because we no longer support...

Note that the `2010.0.0-beta1` version is a consequence of how we currently handle the case where either the `git` command isn't available or the *.git* meta data directory isn't available...

Regarding the ksh version issue. This is what I see using ksh built from the master branch: ``` $ ksh KSH PROMPT:1: set -o vi KSH PROMPT:2: Version A 2020.0.0-beta1-170-gc99e9ff1...

If you need to detect a "real" ksh rather than a clone it should be sufficient to check for `AT&T Research` in the output of `ksh --version`. It would be...

> I am sorry to be repeatitive: 'ksh --version' is of no help. Understood, but there is no simple solution since the legacy ksh93u+ release emits two different strings for...

> I can ask. but see above: ensuring deterministic version string(s) upstream is sure preferable. Agreed, but not possible. I'm thinking we should do the same thing, more or less,...

> in any case ESC ^V and print $KSH_VERSION should definitely always have the same value/output. do you agree? Yes. This type of pointless inconsistency drives me nuts. But there...

> the only clean solution for me seems to always include the commit hash everything else is marginal. **That is not possible** if there is no git metadata; i.e., the...