ksh

It does however, ship with something called legacy ksh - lksh (symlinked to ksh) but which behaves differently than actual ksh, and reports itself as mksh - which incidentally also behaves differently. By "differently" of course I mean so fundamentally modified, our DBA's thought their scripts had been possessed by demons - I was asked to look into an online ordination as to perform exorcisms on our newly installed servers during the next maintenance window. But I digress. The point is, we'll need to use ksh93, which requires installation of the Legacy Add-On Module.

With SLE 12 SP1, we release KSH 93u, which is more stable version 93v. In order to provide a regular update path from 93v to 93u, a higher version number (93vu) has been used for this update.

This is the point at which I learned system administrators apparently struggle with sequential $PATH variables, (dot).[profile] variables, or both, as SLES 12 has solved this manufactured problem by creating an overly complex "alternatives" hierarchical solution in which well-known binaries can be symbolically linked to any number of derivative binaries.

Which might be awesome if it worked right out of the box. Here we see that ksh is actually lksh

No problemo; man-page says --config name will show available alternatives for a link group and allow the user (me) to interactively select which one to use. Easy as pie. Everyone likes pie. So let's check out our options since we've already installed the Legacy Add-On Module, and choose ksh93 as our our back-end symlink:

sles12sp1:/ # update-alternatives --config ksh

There is only one alternative in link group ksh (providing /bin/ksh): /usr/bin/lkshNothing to configure.

Huh. Well let's go ahead and install one, k? Should be easy according to the man-page:

Therefore we MUST provide a slave link, which has to be in a very specific order, apparently, because mine failed with an inaccurate error message before I swapped the /bin/ksh and /usr/bin/ksh in the command below: