General
cancel
Showing results for 
Search instead for 
Did you mean: 

Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

SOLVED
Go to solution
Johan Hoeke
Advisor

Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

we're migrating from HPUX 11.0 to RHEL 3.0. Turns out ksh portability is not what I'd hoped for.
A simple example:
On our trusty HPUX server using the ksh, assuming you are in /dev:
if [ -f tty* ]
then
echo file found
fi
results in "file found"
on RHEL 3.0 the result is:
ksh: [: tty0: unexpected operator/operand
because the wildcard expands to tty and tty0 etc...

The files the script needs to test for have a date and time extention. (like file.20040528) And there can be one or more than one. Our ksh script on HPUX had no problems with this. The same script on RHEL 3.0 chokes on the if exists if there is more than one file. Ofcourse the script in question can be changed, (any elegant solutions anyone?)
but I'm worried that I'll run into other incompatibilities in other scripts and I'll have my hands full if I have to test every single script on the box. Any tips?
8 REPLIES
Mark Grant
Honored Contributor

Re: Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

I think the HPUX example you give is a bug. It should be expanded and it should produce an error.

However, I just tried your code on hpux11.0 and 11i and in both cases, although there was no error, it didn't find the file either.

To be honest, I would really recommend you move away from the korn shell and use either "sh" which is the posix shell on HPUX or bash on Red Hat. You may need to bite the bullet and make a few script adjustments.

Would this do

ls *.20040528 > /dev/null && echo "File found"

Never preceed any demonstration with anything more predictive than "watch this"
Johan Hoeke
Advisor

Re: Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

Hi Marc,

thanks for your reply. my example was a bit stupid, the files in /dev aren't regular files. so it should be like this:
ut23 $if [ -f /usr/bin/lp* ]
> then
> echo file exists
> fi
file exists

actually the script is more like
if [ -f /somewhere/file.* ]
then
dosomething
else
mail somebody that there aren't any files
fi

still annoying that this works on my hpux box w/ the ksh but not on my shiny new linux box with the same shell.

noticed that bash doesn't allow the wildchar there either. so it's not a ksh issue per se and maybe indeed a HPUX ksh bug. Any reactions from the HPUX ksh camp? (if there is such a thing :-)

Jeroen Peereboom
Honored Contributor
Solution

Re: Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

Johan,

I would say it's a bug in HP-UX ksh. Sorry.

'if [ -f .... ]' stands for executing the test command. Test -f expects 1 argument...
I believe test is a shell built-in.
/usr/bin/test also rejects multiple filenames.

Another nice difference can be found here:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=478229

Also expect changes in filenames and locations...

JP
Mark Grant
Honored Contributor

Re: Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

Johan,

The korn shell provided with HPUX is not really a supported product. The korn shell provided with linux isn't that great either.

The default shell on hpux is /bin/sh and although this looks like it might be the Bourne shell, it isn't. It is the posix shell which is a superset of ksh. It has all the features of the korn shell (without the bugs) plus more.

On linux the default is "bash". It is also a superset of the korn shell and although there are one or two places where I think the bash implementation is not correct, they are small and definately debatable points.

I would really urge you to consider testing your scripts using "bash".

The one liner in my previouls post will do what you wanted by the way.
Never preceed any demonstration with anything more predictive than "watch this"
Steven E. Protter
Exalted Contributor

Re: Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

I have found most scripts orginating in POSIX and korn shell on HP-UX port very nicely and function well with bash.

The only modification I've had to do is with the echo command.

The korn shell on Linux has been judged by many peers in this forum as "not ready for prime time" and "introducing more problems than it solves."

There are those who like it though. Caveat Emptor.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
John Poff
Honored Contributor

Re: Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

Hi,

We have a RHEL 2.1 system where our vendor specified that they had to use ksh for their shell scripts. We objected, as the only ksh we could find was pd-ksh [which comes on the discs from RedHat]. The pd-ksh works but it has some limitations, which you have just tripped across. There are other limitations to this implementation of ksh. Check this link:

http://www.cs.mun.ca/~michael/pdksh/NOTES

We pushed back but our vendor insisted on using it, so we finally worked out a deal where the vendor will support any issues with it.

The bash shell seems to be a superset of pd-ksh, so I don't see any reason to use pd-ksh. As Steven mentioned, about the only change is the 'echo' statements. I'd much rather run on a shell that is active and supported. If you check the changelog on the pd-ksh web site, the last version was released in 1999, which doesn't give me a warm feeling for a production system.

JP
dirk dierickx
Honored Contributor

Re: Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

pdksh is not finished yet, there are things missing from the shell that the hpux ksh has.
however some time ago the ksh opened up the source code as well, and you can now get RH packages for it, these are close to 100% compatible. ftp://dan.drydog.com/pub/linux/ksh93-2000.10.31.0-1.i386.rpm
Johan Hoeke
Advisor

Re: Linux ksh (pdksh-5.2.14-21) versus HPUX 11.0 ksh

Everybody thanks for the replies. Seems we have exploited a bug in the hpux ksh in this particular case so we'll fix the script.
Judging from your replies we'll probably be ok with the other scripts. I'll doublecheck any scripts using non-triavial echo statements.

regards,
Johan