AT&T Ksh Timezone bug

[Michael Williams_6]

Hello all!

We've downloaded the AT&T ksh as pdksh doesn't not have sufficient functionality for our scripting needs.

Unfortunately for us, this ksh has a built-in for date which has a bug in it and so isn't picking up that the clocks changed last month.

We can get around this by adding an alias date=/bin/date in the .profile or .kshrc, however, when someone runs a script with #!/bin/ksh at the top, then this information is not passed on to the sub-shell.

Does anyone know how to export aliases, like environmental variables?

Alternatively, can someone suggest a solution that will work with sub-shells?

[Roberto Polli]

being bash a ksh compliant shell you can try to link ksh to bash.

I use it and scripts run fine.
Else try to put an alias to date in the script or specify full path.

Peace, R.

[Nicolas Dumeige]

Hello,

One correction if you let me : pdksh is NOT the ATT Korn Shell, it's a clone developped before ksh could be freely downloaded.

It has limitations that the original one have not.

The real ksh is downloadable at :
http://www.research.att.com/sw/download/gen/ast-ksh.html

Cheers

Nicolas

[Michael Williams_6]

Unfortunately bash has the same limitation as pdksh, we have to use AT&T's ksh.

[Roberto Polli]

Sorry! Can you explain which kind of limitation you have found for bash and pdksh?

Peace, R.

[Steven E. Protter]

If you have to use it, you have to work with the bug. I think attempts to bring the korn shell to Linux are half-baked at best.

I have found that /bin/sh has run correctly almost all of my korn shell based scripts that I was forced to port from hp-ux to Linux.

Just a thought.

You could also handle such issues as timezone by setting a variable globally in all scripts that lets them calculate from there.

SEP

[Nicolas Dumeige]

Roberto,

Try that one :
pdksh> echo value | read var ; echo $var
<-- Null
ksh> echo value | read var ; echo $var
value

Nicolas

[Bruce Copeland]

Let me see if i have this straight. You want

echo value | read var; echo $var

to mean

echo value | (read var; echo $var)

instead of

(echo value | read var); echo $var

Ie. you want the | operator to take precedence over ; I'm no scripting guru, but this is at odds with most standard programming languages and is one reason many serious programmers are not very fond of scripting. Why not simply bite the bullet and find another way (for example, using parentheses)?

Bruce

[Stuart Browne]

Bruce, nah. The issue Nicholas is talking about has to do with most GNU shells treating pipes as sub-shells, thus not propergating variable changes back up to the parent.

There's ways around that, i.e.:

read var < <(echo blah)

But that's an aside.

If the AT&T ksh implementation has a borked inbuilt 'date', then do one of two things.

- ensure that all of your scripts which will use it use fully pathed commands: /bin/date

- force the hash-bang calls to initiate a login-shell, thus processing /etc/profile etc. so you can force your own aliases.

[Michael Williams_6]

Hi Stuart, going through all our scripts in CVS to ensure they have the line alias /bin/date might take a bit of time, so I like the look of option 2, how to I tell the OS to run the profile with scripts that have #!/bin/ksh at the top?

Mike

[Fred Ruffet]

Stuart,

I've been recemtly in the same troubles for aliases. Someone on this forum gave me the solution of setting in your .profile the ENV variable to a script where you set your alias. For every ksh launched, this script will run.
You should also have a look at -x and -t options for alias.

Nicolas,

"| read" is not a limitation, it's a feature. There is no normalization on the subject and the POV of HP-ksh coders and other shells ones are different.

For HP, when you do "echo toto | read a", "read a" is executed by your curent shell and a new one is created for echo.

For bash, or other shells, current shell does echo and a subshell does read (so its variable can come back to his father).

But, if you do something like
#(a=pro ; ls) | grep $a
it won't work on HP and work on others...

[Roberto Polli]

Maybe using 'ed' to modify multiple files can be the quicker solution...

Peace, R.

[Michael Williams_6]

Hi Fred,

Thanks for your suggestion, setting up the $ENV variable certainly does cause any interactively started ksh shells to have the same environment information, however this does not work with scripts with #!/bin/ksh at the top...

Any ideas?

[Fred Ruffet]

It does work for me, but I use "alias -x"

Regards,

Fred

[Michael Williams_6]

Hi Fred, that's really interesting as it doesn't for me :-(

Take a look at the tests I've run:

michaelw@abacus4: echo $ENV
/homes/michaelw/.kshrc
michaelw@abacus4: grep date $ENV
alias -x date="/bin/date"
michaelw@abacus4: type date
date is an exported alias for /bin/date
michaelw@abacus4: date
Thu Apr 29 13:56:32 BST 2004
michaelw@abacus4: ksh
$ date
Thu Apr 29 13:56:35 BST 2004
$ exit
michaelw@abacus4: cat test.sh
#!/bin/ksh
type date
date
michaelw@abacus4: test.sh
date is a shell builtin
Thu Apr 29 12:56:42 GMT 2004

Looking at the suggestions in this thread already, I've tried setting up a $ENV variable, I've also tried alias -x, these both work fine if I kick off as ksh, but if I stick it in a script with #!/bin/ksh it all goes wrong!

What version of ksh are you running? Does your ksh default to having a builtin date? If not this could answer why it works for you and not me!

[Fred Ruffet]

Have a look at the following :

/home/me> echo $ENV
/migration_hp/users/ga01400/test
/home/me> grep date $ENV
alias -x date="/bin/date"
/home/me> type date
date est un alias exporté pour/bin/date
/home/me> date
Jeudi 29 avril 2004 16:39:10
/home/me> ksh
/home/me> date
Jeudi 29 avril 2004 16:39:24
/home/me> type date
date is an exported alias for /bin/date
/home/me> cat > test.sh
#!/bin/ksh
type date
date
/home/me> chmod +x test.sh
/home/me> ./test.sh
date is an exported alias for /bin/date
Jeudi 29 avril 2004 16:40:14

What I see is that your prompt changes when you launch your second ksh (i.e. it is NOT a login shell) and this might be your problem.

Regards,

Fr

[Joel Kammet]

This all seems very strange.

I downloaded & installed the ATT ksh to use in my Unix Shell Programming class last semester. I never noticed any problem with date. I'm running it under Red Hat 9 in a desktop and in a notebook. The date command returns the correct EDT whether I execute it from the command line or in a #!/bin/ksh script. I never had to do anything special to get it to work -- just installed it locally according to the ATT instructions.

One thought: did you set up ksh to be your login shell? I left bash as the login shell, & just run ksh from the bash command line. As far as I know, all of my scripts ran the same under this setup as they did on the Sun workstations at school, even the ones that did not run correctly in the bash shell.

[Michael Williams_6]

Wow, lots of responses going on here!!

Fred: KSH is my login shell and the second shell was running correctly, however the PS1 information is stored in my .profile and not .kshrc, which is why it showed a $ and not the normal PS1 prompt.

Joel: The pre-compiled ksh from AT&T's site doesn't have date built-in (which is where all our problems are coming from), so the problem doesn't exist in this version, but we needed some extra functionality, and the developers didn't spot the bug in the date builtin and can't re-compile it until the project their on is over.

[Fred Ruffet]

What I mean by "login shell" is a particular shell which execute you profile. As long as your new ksh is not a login shell (man ksh or bash or whatever shell you want), you dont set environnement :
. ENV is not set, so you don't run the script that set your alias
. PS1 is not set, and so your prompt is not set anymore
. TZ is not set, and so you don't seem to be in the correct time zone any more.

Try to replace your
#!/bin/ksh
by
#!/bin/ksh -
(force shell to be a login shell)

Regards,

Fred