Anybody using the pd-ksh Korn shell on a production Linux box?

[John Poff]

Hi,

We have a vendor who is porting their product to Linux [RH AS 2.1] for us. They are used to running on HP-UX boxes and have settled on the Korn shell as the standard for all their shell scripts which run their application.

They have taken a look at the Bash shell and they miss some of the functions in Korn shell which they say Bash doesn't have. They want us to use the pd-ksh Korn shell, which ships with RH AS 2.1. I've done some checking on that package and it looks like pd-ksh hasn't been updated since July 1999, so I'm a little bit worried about relying on it for production scripting.

Any of you have any experiences with pd-ksh?

JP

[Steven E. Protter · Accepted solution]

John,

Your worried are valid. I played with a ksh clone and had all kinds of trouble.

In the end, its better to change the shell statement in the top of the scripts and do extensive testing to make any necessary changes.

Thus far, I've ported hundreds of HP-UX Korn shell scripts and had NO production problems on my Linux bash shell server.

I know, not exactly what you wanted. I still cringe when I think of that experience.

SEP

[Jerome Henry]

I one of the University, one folk used to set pd-ksh instead of bash for 'compatibility reasons'. His idea was that bash hadn't all the functionnalities of ksh.
But nor does pd-ksh, which doesn't implement all AT&T ksh functionnalities !

Worse, as you noticed, it didn't evolve since 1999, which is indeed a problem in many recent scripts.

To give you a few ideas of the problem we had to face, it doesn't have wildcards support (!), pushd, popd, directory stack commands, notify shell build in, poor history support, and so on.

Basically, we turned back to bash, which indeed implies searching a few for some instructions and porting, but most of the time you'll find the equivalent instruction or way round on google, by searching 'instruction +bash'. You'll then of course will have to take care about path, but that's not a big issue.

hth

J

[John Poff]

I was afraid of that.

The vendor has listed about a half a dozen things that they can do in Korn shell and not in Bash. I think the things are minor, especially compared to the things that pd-ksh doesn't handle [wild cards, etc.], and the fact that the pd-ksh project hasn't moved in four and a half years.

Thanks for your help!

JP

[Gregory Fruth]

You can also get the real AT&T ksh:

http://www.research.att.com/sw/download/
http://www.kornshell.com/

[Sorrel G. Jakins]

The whole thing boils down to posix compliance. HPUX's ksh is posix compliant, and hence has very few compatibility issues when you are trying to get something to work. When a vendor starts bleating about bsah incompatibility, just ask them if their scripts are POSIX.2 compliant, and if not, why not? Most of the incompatible extensions above POSIX.2 in ksh and bash are only for the really advanced power users/scripters. My experience has been that a lot of times the objection to bash boils down to something simple like ksh running $HOME/.profile or $HOME/profile.ksh, whereas bash uses $HOME/.bash_profile.

If the vendor gives you a list of what ksh can do that bash cannot, post it here, I'll be watching...

[John Poff]

Greg,

Thanks for the link. I'll take a look at that ksh. It might solve my problem.

Sorrel,

Here is what they are complaining about:

ksh:
1. 'typeset' allows for 'local' variables in functions

2. 'trap' has separate effect in main-line code and functions

3. 'echo' uses platform native 'echo'

4. 'print' replaces echo and is standard across all supported platforms

5. 'print' supports escaped characters such as '\n' etc.

6. Allows use of wildcards as case statement targets

Bash:

1. Uses 'local' - not available in ksh.

2. 'trap' effects both main-line code and functions

3. Differences across platforms

4. Not available

5. Must use 'echo -e' for same result

6. Not available


Half of their objections are about 'print' vs. 'echo' which really seems minor to me. I haven't messed with case statements in Bash so I'm not sure about that one, but I bet there is a way to do it. The 'trap' function makes sense in Bash and seems a little dangerous the way it is described in ksh.

I've been pushing for the vendor to just rewrite their scripts to work with Bash. I understand that they don't want to keep up with two versions of scripts, but if they could write them to work with either ksh or Bash it would seem like a win for them.

JP

[Stuart Browne]

wildcards in case statements? they sure do work!

The 'echo' thing I agree is a pain, which is why alot of the scripts we use now have sections like this at the top:

if [ "$(echo -e test)" = "-e test" ]
then
ECHO="echo"
else
ECHO="echo -e"
fi

$ECHO blah

Those that don't need '-e' don't usually unerstand it at all.

As for 'print', well, all of the abilities it gives you can be done with standard file descriptor redirections, or is inbuilt in 'echo' already. None of the scripts we use in our production systems use it. (Note: we use the SCO Unix 'ksh').

All of the scripts we use under SCO had only minor modifications to work happily under pdksh. These changes were back-ported into the original, and is now in place for both.

[Sorrel G. Jakins]

er, Stuart, I hate to be pedantic but that is now spelled $CO.

(for non-US charactersets, this is a joke about SCO that replaces the 'S' with a US dollar sign)

Sorrel

[John Meissner]

Just to add. At the company i work for we have 40 Linux Machines. Many of which are in production. We have the ksh shell installed on the server due to the needs of certain appliations. However. Whenever possible I always use bash to do the scripting on those boxes.