Skip to main content

Why AIX Admins Should Know vi and ksh

People are pretty passionate about the tech that they use. That’s hardly a news flash. It can be argued that none of us is truly objective, but I’ve been through enough heated discussions over time to understand that strong feelings exist about computing.

So we may as well cop to our biases. I’ll start. I freely admit to being an AIX bigot, and I know that colors how I see the world.

What about you? Do you prefer Windows or Linux or MacOS on your desktop? I would say that MacOS and Windows run into these issues less than Linux, but your mileage may vary. But is preference even the most important thing? If disparate desktop environments are being used, the simple and straightforward can become more complicated. Sure, workarounds are doable, but that eats up time that could be spent collaborating.

So would it be better that everyone use the same popular OS to maintain a friction-less environment? If I can get Zoom or Webex or Microsoft Teams running on a Windows machine, it’s a safe bet you can get it to work on your Windows machine. That means we can quickly get on a shared session and work together.

This sort of thing is hardly new. I worked at IBM in the early 1990s, when the company was exhorting us to eat our own dog food. That meant using Lotus Notes for our mail environment, along with Lotus Office Suite for word processing. As a result, the process of exchanging incompatible files with customers was typically challenging. I ended up requesting permission to run Microsoft Office products. It was the only way to resolve our issues, and once we were on the same software, our problems went away.

Of course the counter argument is: shouldn’t the quality of the product matter most? What about viruses and malware? That code is often being written to infect the masses that run Windows. The argument for running Linux or MacOS is they give you a better chance of avoiding those issues.

This extends to the enterprise. We hear about ransomware encrypting and locking Windows servers, primarily. I’ve not heard of similar things happening with AIX or IBM i running on POWER.

Of course we can drill way down here. Even among AIX users, strong preferences exist over which tools and commands to deploy and run in any given situation. For instance, what’s your favorite editor? Are you in the vi camp? Emacs? Do you prefer something with a GUI, or something like Pico? Just typing this out, it seems like such a minor consideration. And yet, the opinions are many, and the feelings are real.

What about your favorite shell?

A Unix shell is a command-line interpreter or shell that provides a command line user interface for Unix-like operating systems. The shell is both an interactive command language and a scripting language, and is used by the operating system to control the execution of the system using shell scripts.

Most experienced Linux users are pretty comfortable with the bash shell. But do you know you can install that shell on AIX? Use the chsh command, or change your shell to bash. But be careful:

AIX default shell is the Korn shell. There are quite some other shells one can use with AIX. However IMHO anything but ksh or ksh93 in AIX is about 99.xx% compatible only. The missing .xx% can cause you some headaches when you rather would concentrate on some other os related problem. Therefore, as an AIX administrator I’d always recommend to stick to ksh.

On that note, is there anything more frustrating than troubleshooting a problem and then discovering it was self-inflicted? Changing your root shell can lead to problems:

Question: Can I change root or another system account user’s default shell from ksh to ksh93, or bash?

Answer: The Korn shell (/usr/bin/ksh) is set up as the default shell. The default or standard shell refers to the shells linked to and started with the /usr/bin/sh command.

The AIX Operating System is tested with SHELL=ksh in all system account script processes, unless otherwise defined in the script. Using chsh or otherwise modifying system user accounts in /etc/passwd to change a system account shell to non-ksh could result in script failures at run time. Users are advised to test any default shell changes carefully in their environment.

Note: The bash shell is an open source product, and is not supported by AIX Support cases.

IMPORTANT: Do not replace /usr/bin/sh or /usr/bin/ksh with other binaries!

  • The system is in 32-bit mode in phase 1.
  • The kernel cannot load a 64-bit binary until phase 2 of the boot.
  • There are shell scripts that run during phase 1 of a system boot.

# file /usr/bin/ksh
-> executable (RISC System/6000) or object module
# file /usr/bin/ksh93
-> 64-bit XCOFF executable or object module not stripped
# file /usr/bin/bash
-> 64-bit XCOFF executable or object module

To reiterate: Do not change root’s default shell!

I get it, you really like bash. You really don’t like ksh. Tough. You’re a professional. Learn how to navigate with ksh. Get so proficient at it that it becomes second nature. You need to master it. If you’re new to AIX, there are resources. This old book remains an excellent Korn primer. Here’s another older book. Same deal.

As I’ve said often, get on a system and get hands-on. Trial and error—while always trying to accomplish something, day in and day out—is the best way to learn in my experience. The time to learn is not when the system is down; that’s when you need to know. When a system is down and maintenance must be performed, an expert is needed: you. This is why you must be well-versed with the system’s built-in tools. If you cannot already run vi and edit a file without thinking about it, practice more. If you cannot log into ksh and navigate your shell history and edit commands on the fly, practice more.

Arguments can be made, sides can be taken, but my position is that knowledge of vi and ksh represents the bare minimum for being able to maintain an AIX system.


Key Enterprises LLC is committed to ensuring digital accessibility for techchannel.com for people with disabilities. We are continually improving the user experience for everyone, and applying the relevant accessibility standards.