Error messages should use colors and other highlighting

[krader1961]

While working on issue #507 I noticed that ksh error messages are unadorned plain text even though the text displayed by the man pages produced by Sphinx use highlighting such as bold and italics.

It is 2019. Terminals that support black & white highlighting via bold and underline have been the norm for more than four decades. Terminals that support colors have been common for more than two decades. Why aren't we taking advantage of those capabilities when displaying error messages?

[jghub]

because people might want to write and parse(!) log files in their workflows and do not want to be plagued by escape sequences inserted for switching colors and emphasis? ksh does not need a candy store approach. it would be (another) step into a wrong direction.

[dannyweldon]

@jghub Whilst I agree with you, most utilities that have color highlighting only display it when writing to a console, unless there is a switch to force it. eg. for gnu ls:

      --color[=WHEN]         colorize the output; WHEN can be 'always' (default
                               if omitted), 'auto', or 'never'; more info below

I personally use a little trap for my interactive shell only that echos something like "Exit: 1" in red if a command fails:

trap -- $'print "\E[31mExit: $?\E(B\E[m"' ERR

This helps me to notice the error and what the exit code was without having to check, and it works for ALL commands.

However, I'm not really thinking this is a priority. On the other hand, syntax highlighting on the command line, I think would be awesome, but I think it should be an external builtin that is loaded if wanted in .kshrc and that is used in a KEYBD trap. I have done some experiments with this with mediocre results so far.

I have also been thinking that some thought should be put into having a standard library that encapsulates all the colors (256 now) and highlighting and perhaps defining a custom escape sequence such that these types of things can be embedded in strings without having to know the exact escape sequences like my example above.

Then we can move on to defining some custom variables so we can define themes like ohmyzsh but that would be external to this project.

[krader1961]

@dannyweldon FWIW, I meant for error messages to be styled only if written to an interactive stderr stream. Error messages written to a file should be plain text. Sadly, he who must not be named, has decided to interpret all my proposed changes as uncharitably as possible. They seem to think I'm an idiot rather than a senior software engineer (formerly at Google) who has been dealing with such issues for four decades.

P.S., One of my very few complaints regarding Google software engineering standards was the choice to record timestamps in log files with an implicit US/Pacific timezone (or equivalent) offset rather than UTC. Something that needlessly complicates transforming those log entries into the timezone of the reader regardless of whether or not they live near Mountain View, CA. That choice is understandable given that the founders were Stanford University students. Which means using the local timezone made it easy for a human (the Google founders) to read the log files without post-processing. But it is a good example of the sort or narrow minded, provincial, thinking that tends to create problems in a lot of software projects down the road if they live long enough. Including the Korn Shell.

P.P.S., This enhancement is most definitely not a priority. I'd like to see a much saner key binding mechanism implemented as one example of a higher priority change. This is simply an example of the sort of change that would make ksh a much better interactive shell.

[jghub]

@dannyweldon:
as with many things, tastes differ. if colorizing were done like by the gnu tools (grep, ls etc including intelligent redirection w/o color) and the default were "OFF": fine with me. I mostly don't want/like it. I definitely find the behaviour of fish in this respect (that's what krader has in mind, quite obviously) totally distracting/annoying.

but the assessment by krader that this is "the sort of change that would make ksh a much better interactive shell." is another non-sequitur. "nice to have for some" at most.

admittedly, it of course depends on your targeted user group. krader's persistent and uncorrectable misconception is that ksh is not a "real" scripting language and thus not usable (and used by 'nobody' in his world) for programming. I would argue that serious programming/scripting is the only use case where ksh is superior to bash/zsh (to name the obvious contenders). so performance (which is severely harmed in ksh2020 relative to ksh93u+ no matter what krader states on the mailing list to the contrary) and the feature set of ksh (plus predictability of behaviour, standards compliance, stability) is what will count in the long run to maintain a user community (but a smallish one). those people will also use ksh interactively but mostly don't care for gimmicks like colourful error messages. and if they would they would do it themselves.

regarding the other users, I would say it is true that most linux/unix/osx users do make only very basal interactive use of the command shell to start some program and issue ls and grep or find (if they dare that ;)). so for these users superficial features like color might be more relevant. but rather obviously the whole field of command line editing, prompt customization and file and command completion is way more relevant for these people and only if the users really are going to choose their login shell themselves (they probably wont: the sysadmin has done that already).

so if ksh could be made competitive to bash in this respect (notably programmable command (args) completion) the perception that ksh is clunky in interactive use might go away. colorful output would be at the very bottom of the list of interactive behaviour changes to implement.

I also would say, to make such casual users happy with interactive ksh behaviour would be OK only if it does not interfere with the needs of serious users. in any case it wouldn't really make a difference whether these people use bash or ksh as their login shell (and they won't care) since they don't use the capabilities of either, really...

so, as in so many things in this project, krader's aims and priorities are wrong and he will not change for the better, that seems by now a sure bet. ideally this project would need a reset and a different maintainer, but that is not going to happen.

all this would be irrelevant if ksh2020 would not aim at displacing ksh93 (by claiming that it still is ksh93 and thus misleading some distro's package maintainers into adopting ksh2020 as a replacement of ksh93u+)). if this does not happen (and is reverted where it has already happened) and ksh2020 is provided only as a choice under an unambiguous name (like ksh2020) all would be good again and knowledgable users would pick the real thing and wait and see whether ksh2020 ever can prove to be superior to ksh93u+ by any relevant metric for which they care (coloured error messages won't be on their list I predict).