4

I'm not a system administrator, but my organization is considering replacing /bin/sh in Red Hat Enterprise Linux 6+ with a hard link to /bin/ksh. How foolhardy would this be?

The background to this question is that we're migrating a third-party application from AIX 5.3 to RHEL 6+. This application executes shell commands by invoking sh. The shell commands themselves are user-defined, and in practice have been written for the Korn shell (ksh). This works in AIX because IBM delivers sh as a hard link to ksh. Over the years, thousands of user-defined commands have been created and stored by our team.

We've found that some of these commands fail in Red Hat, because sh in Redhat is a symbolic link to bash. When invoked as sh, bash runs in sh emulation mode. The problem is that our ksh-specific commands (e.g., print) that used to work in "fake sh" in AIX do not work in "fake sh" in Red Hat. We don't yet know the full scope of the incompatibilities.

In chapter 10 of Learning the Korn Shell (ISBN 0-596-00195-9), Bill Rosenblatt and Arnold Robbins say: "[W]e want to emphasize something about the Korn shell that doesn't apply to most other shells: you can install it as if it were the standard Bourne shell, i.e., as /bin/sh." ... "Many installations have done this with absolutely no ill effects."

How foolhardy would it be to do this in Red Hat? My concern is that system or 3rd party scripts in the Red Hat installation might depend on idiosyncracies of how sh is emulated by bash. If so, solving our immediate problem with a hard link to ksh could cause unknown breakage throughout the system.

Improve this question
6
  • 3
    I wouldn't do it for the system but create a chroot and have there /bin/sh as /bin/ksh
    – Ulrich Dangel
    Commented Apr 4, 2013 at 14:28
  • 1
    Might it not be easier to go through the user scripts and change /bin/sh to /bin/ksh? That way you're compatible with everyone - the old users who are used to using ksh-specific features, and new ones who might want to write for sh-specificity.
    – MattDMo
    Commented Apr 4, 2013 at 15:23
  • Another warning: ksh in AIX 5.3 is the old ksh-88, while the RHEL package is ksh-93. Generally this should work but there may be small incompatibilities here too.
    – mattdm
    Commented Apr 4, 2013 at 15:30
  • @MattDMo: The third party application itself is invoking sh. The way it works is that the application generates a script, writes it to a temporary file, and calls sh to execute it. Even if we were to include a #!/bin/ksh shebang line, the temporary script still gets executed by sh. (I verified this by writing a Korn shell script that has the shebang line, and uses the ksh-specific print command. Then I executed the script using sh, and got the command not found error.)
    – Spacewaster
    Commented Apr 4, 2013 at 15:57
  • @UlrichDangel: chroot sounds like it would be considerably safer. I haven't previously used chroot, but will mention it to our sysadmins. Other alternatives would be to ask the vendor of the 3rd party app for a modification to their app, or to review all of our user-defined shell commands for portability to RHEL's "fake sh".
    – Spacewaster
    Commented Apr 4, 2013 at 16:02

1 Answer 1

Reset to default
2

System-wide, this would be very foolhardy for exactly the reason you suspect - it will cause massive breakage in startup scripts and system utilities that depend on sh-compatible behavior. As Ulrich says, a much safer alternative is to crate a chroot, or simply set the default shell of all new users to /bin/ksh though this may not do exactly what you want.

Improve this answer
2
  • Thank you. This certainly sounds like a correct answer, but I'll wait to see an upvote or two before accepting it.
    – Spacewaster
    Commented Apr 4, 2013 at 18:06
  • The comments were pretty unanimous that this would be a bad idea. So I'll take this as the answer.In the meantime, I found that the third party application dumps out the commands and executes them with sh -c. Provided the first "command" is a shebang line (#!/bin/ksh), this does work as intended. My previous test was just using sh, without the -c flag. Thanks, all.
    – Spacewaster
    Commented Apr 4, 2013 at 19:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .