Why I Use Korn Shell Everywhere

The first thing I do when I log into a system, including Solaris, HP-UX, FreeBSD, and Linux is exec ksh. Whatever for?

Consider this fact: the root shell on FreeBSD defaults to C shell; HP-UX defaults to the POSIX shell (without history); Linux almost everywhere defaults to bash. All of these shells are different in various ways. It is possible you might log into three separate machines and get three separate shells with three different ways of handling things.

Using Korn Shell means that all of these systems will be standardized on one shell, and every system will act the same when you interact with it. There will be no surprises – and surprises at the root command line often translate into disastrous errors.

On HP-UX, using ksh has the additional benefit of enabling history for root – although the security risks of this make this a dangerous benefit: best to erase history after you log out and to make sure that history is independent for every root shell.

What makes this possible is that the Korn Shell is available virtually everywhere, including FreeBSD, Linux, Solaris, and HP-UX – whereas other shells are not (which includes C shell, Bourne shell, and bash).

7 thoughts on “Why I Use Korn Shell Everywhere”

  1. What are the major differences between ksh and zsh? I’ve been thinking about changing my default shell (from bash), but haven’t yet taken the plunge. Is zsh as ubiquitous as ksh these days?

    1. I looked at zsh when I was looking for a suitable free version of csh (I used csh long before I switched to ksh).

      However, zsh is not on HP-UX or Solaris or AIX – which makes it bad for normal sysadmin duties. Most Linux systems do not come with zsh but I dare say all of the big variants come with zsh available for additional install.

  2. I’ve actually been coerced into doing the reverse with bash. I liked ksh but when I came in to my current job bash was already there, and developpers didn’t like the idea of ESC-k (can’t argue with that!). They write all their maintenance scripts in bash… on HP-UX. Not a good idea cause if bash stops working because libiconv barfs, my phone will ring. I normally apply the following rule: write root sysadmin scripts using the default shell and leave everything else to whatever users want, at their own risk.

  3. If you wish to have independent history file for every session, why not just use HISTIFLE and set it to something unique like $$?

    export HISTFILE

    From man ksh –

    HISTFILE If this variable is set when the shell is
    invoked, then the value is the pathname of
    the file that is used to store the command
    history. See Command re-entry.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: