"The Linux Gazette...making Linux just a little more fun!"

ksh Keybindings (vi Keys)

From Robert Lynch on Sun, 20 Feb 2000

Hi-

My wife is an SCO sys admin whose business bought her a Dell pre-configured RH 6.0 box for home use. She's used to ksh on SCO, with default vi setting. She finds this broken with bash. I have tried to fix it, including installing pdksh, but no joy.

Say she types:

$ ls
$ who

then hits ESC + up arrow. Instead of moving through the command history, a "[A" character appears. I tried re-mapping the arrow keys but nada.

Please NOTE: I've been working on this for a while, and have seen several postings, to the effect "just set -o vi". Ain't this!

TIA. Bob L.

set -o vi under bash works fine for me. I've used it occasionally and I've had students use it for years.

However, vi normally uses the letters h,j,k, and l for its cursor controls. The [Up Arrow] and other keys are not traditional vi key bindings (though most modern versions of vi will also accept them if your terminal is properly configured using the appropriate TERM variable in association with a decent terminfo or termcap entry).

Can you run 'vi' (the editor) and/or emacs or xemacs from this command prompt? Is it in an xterm or from a text console? Are you (and she) accessing this through telnet? What terminal emulation is this going through?

If you can run 'vi' or 'emacs' within that terminal window, or console/terminal session then your TERM environment setting should be sufficient to support the vi keybindings used by bash, pdksh and ksh). My quick tests with pdksh, ksh '93, and bash all show that the [Up Arrow] key IS recognized by the vi keys handlers in any of them. I tested this from a text console with TERM=linux, from under the 'screen' utility with TERM=screen, and from an xterm with TERM=xterm. This is all on a Debian/Potato system with all recent updates applied for all software (yesterday).

So I don't know what is wrong. You'll want to play with the 'k' (vi up key) to see if that works, and play with the TERM variable (especially if you're connecting through your net using some MS-DOS or MS-Windows telnet client). You might also want to check if you are using some unusual key mappings on your Linux console (the loadkeys command) or in your copy of X (the xmodmap command). Again, if you have vi and emacs working normally, then these should not be problems for you.

Moving on to the larger issues of making your wife feel at home on here new system. If she's used to SCO's ksh then she might find some of the minor differences between it and GNU bash (the default Linux shell, from the Free Software Foundation --- https://www.gnu.org). There are even differences between pdksh and ksh '93, and even more minor ones between pdksh and ksh '88.

I don't know which ksh ships with SCO UNIX nor even which version of SCOnix that your wife is using. I'll assume she's using a recent copy, and that it shipped with the most recent Korn shell.

I suppose the best advice would be to get the real Korn Shell (ksh '93) from David G. Korn's web site: https://www.kornshell.com. Just follow a couple of obvious links (Software, "Official AT&T Release...") and fill out the little form.

Note that this is NOT free for commercial use. It is also NOT open source. You can read their license agreement for all of the details.

If your use will be within those restrictions than you can get this for your wife. If she's used to subtle nuances of ksh --- and especially if she does serious shell scripting involving associative arrays, co-processes, and floating point mathematics then she'll be happier with the "real thing" then she will be with bash or pdksh.

Most shell users wouldn't know the difference. However, ksh '93 (the most recent major release of the package) is the "king" of Unix command shells. It has a number of features which are unique to it (particularly in support of associative arrays).

There's a pretty good, and short, article co-authored by the creator of the Korn shell that discusses some of the features that make ksh '93 unique which was published by the Linux Journal and can be read on their web site at:

https://www2.linuxjournal.com/cgi-bin/frames.pl/lj-issues/issue27/korn.html

More information about pdksh can be found at the web site of its current maintainer, Michael Rendell at:

https://www.cs.mun.ca/~michael/pdksh

As far as I know pdksh and ksh are the only shells to support co-processes. So, if your wife uses those she'll definitely want to use one of them. Bash doesn't seem to support co-processes, yet. I think it's on their wishlist.

(For those that don't know: Co-processes work something like this:

		$ bc |&
		[1] 12345
		$ print -p '1234  * 4567890'
		$ read -p result
		$ echo $result

		...

		$ print -p quit
		$
		[1] + Done	bc
		$

I started a copy of the "big calculator" (bc). The |& operator makes it a "co-process" --- running with its stdin (standard input file stream) connected to one pipe from ksh/pdksh and its stdout (standard output file stream) connected to another. Then I printed a value into that special co-process pipe (print -p) and read that value back out (using read -p). I can then print other transactions into this co-process and read other results from it. This allows me to have one process loaded, maintaining state, and available for work. In shells that don't support co-processes I'd have to maintain my own state, and keep re-executing this command (possibly with quite a bit of extra over-head in providing my intermediate results/state back to the new instance of the program).

So, co-processes are one of the more interesting innovations of the Korn shell. Such things are relatively easy to do from C, but ksh and pdksh are the only shells that interactively provide these at a high level shell prompt.)

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 51 March 2000

HTML transformation by Heather Stern of Tuxtops, Inc., https://www.tuxtops.com/

					1	2	3	5
				5	6	7	8	9
10	11	12	13	14	15	16	17
18	19	20	21	22