Ksh compatibility

[Rycieos]

This issue is to log research and work done to make Liquidprompt compatible with more shells.

Right now, Liquidprompt claims to work with Bash and Zsh only, which it does well. There are no trackers in Liquidprompt, so there is no way to know the Bash/Zsh user share, but I would guess that the Bash user share is higher (since Zsh users often prefer Oh My Zsh), and quick scan of self reporting from the issues would back that up.

Since (hopefully) a stronger test suite will be coming soon, it makes sense to evaluate what other shells Liquidprompt can support without extra work.

Classic Bourne shell should be out, since it's so hard to find now and doesn't support POSIX.
POSIX shells like ash and its derivative dash are unlikely to be good ideas, since they try to stick closely to the POSIX standard. This is good for speed, but ironically, since they ship with less features, many of our tests and checks would have to fork out to awk or sed, which would actually be slower. They are also not designed to be used as login shells, so it's probably not a good idea anyway.

Ksh is a possible candidate though. While ksh93 is obviously from 1993, it has been patched since then to work on many systems, and it is the only shell that some systems ship with. There are also some derivatives (other than bash) like pdksh and mksh. While I don't personally like or use ksh, it seems that Liquidprompt could work in it with little modifications.

Input is welcome from all.

[Rycieos]

Here is what I have found so far:

1. Ksh93 is surprisingly feature rich. It's quite close to Bash in most areas. Ksh88 is not so much, but it is also very hard to find. From now on, when I say Ksh I mean Ksh93.
2. Ksh lacks local and declare, but has typeset. Bash and Zsh have all three, but they all are aliases. While Liquidprompt mostly uses local, it also uses typeset a few times, and a simple s/local/typeset/ should just work.
3. Ksh only treats typeseted vars as local if they are declared in a function name { ... } style function. The name () { ... } style is provided for compatibility with Bourne shell, and therefore doesn't have local variables. Bash and Zsh don't work like this as they didn't try to keep Bourne compatibility a top priority. In Bash and Zsh the different styles are the exact same, so there would be no downsides to switching.
4. Not a drawback, just noting that Ksh supports all the [[ ... ]] style tests that we are using from Bash and Zsh.
5. Ksh doesn't support echo -E. I haven't dug into this one a ton, but my guess is that we can work around it, since the reason that it doesn't have that flag is that it doesn't support escape sequences in echo, so it doesn't need a flag to tell it to ignore them. However, I want to move away from functions returning data via stdout (since it is slow) and move to storing in a ret or similar variable. This would make this echo problem moot.
6. The two largest downsides are PS1 related: Ksh has no \w or similar escape codes. If you want hostname or PWD in the PS1, you need to reference those variables or commands manually. Liquidprompt does some of this manually already, but it's nice to let the shell handle it, both for speed and portability to subshells. Not completely a deal breaker, especially since Ksh is faster than Bash.
7. Ksh has no PROMPT_COMMAND equivalent. If you want something to run before generating PS1, you must put it in the PS1 definition: PS1='$(my_command)'. Speed shouldn't be an issue, since again, Ksh is faster than Bash. But this could limit our options.

I'm not convinced that this is worth it. If there was user interest in Ksh support I would go for it, but as it stands, Ksh users might have to loose out on some of the advanced features of Liquidprompt.

I won't throw away the shell testing script I built for this, and I'll leave this issue open for user feedback. But for now I'm shelving this idea.

[Rycieos]

I think this hope has hit a dead end.

While trying to port my latest Liquidprompt 2.1 develop branch to Ksh, I discovered a quirk of how it does local variables. (I say quirk, but it is actually more standard in programing to do it this way than how Bash and Zsh do it).

$ function foo {
  typeset var="foo"
  bar
  echo "$var"
}
$ function bar {
  var="bar"
}
$ foo
foo
$ echo "$var"
bar

Function foo() gets a local variable, and unlike Bash and Zsh, functions called from inside it do not get access to that local variable. This means there is no way to return values from functions unless you are assigning them to global variables or echoing strings to stdout and capturing with subshells. This is so against how Liquidprompt works that I don't see a way forward here.

Since there was never any interest in porting to Ksh besides my own masochistic purposes, I am canceling this.