We got our ksh from David Korn:-) Seriously, it's "Version M 1993-12-28" I've also tried the install using pdksh 5.2.14, with the same results.
The install WORKED with the supplemental pdksh! IMHO, this isn't really a good solution. An installer script should be robust enough to work on a variety of systems. I realize not all configurations can be tested, but it seems like we've found a ksh/pdksh incompatibility that should be addressed. Again, just my 2 bits. -Bill BTW - Sorry I missed the local variable/function bit regarding read only... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ottomeister Sent: Wednesday, September 13, 2006 2:10 PM To: SunRay-Users mailing list Subject: Re: [SunRay-Users] SunRay 3.1 on Suse 10|RHEL|<any OS != Solaris> On 9/13/06, Quayle, Bill <[EMAIL PROTECTED]> wrote: > The SUNWuti-3.1-32.i386.rpm contains a library called "iu_lib" > On line 466 of that file, and within the GetPackagePath function is the > line: > typeset -r ProductName="$1" > When the GetPackagePath function is called from the installer, it tries > to set ProductName, which is, of course, read only and cannot be set. A variable defined read-only by 'typeset -r' can have its value set by the definition statement, and that's exactly what's happening on that line. *Subsequent* attempts to change the value of the variable will fail. Variables defined by 'typeset' within a function are local variables, for a slightly funky definition of "local" that includes the function that defines the variable and any functions called by that function. GetPackagePath doesn't call itself or any other functions so there can't be a clash caused by recursion. When GetPackagePath returns the ProductName variable should disappear, and on the next call to GetPackagePath a brand-new ProductName variable should be created. What seems to be happening in the cases where this blows up is that the shell does not forget the ProductName variable when the GetPackageName function returns. It's as though the shell keeps the variable's definition intact, such that the 'typeset -r' invocation in the next call to GetPackageName is treated as an attempt to assign a value to an already-defined read-only variable, and that's an error. > I'm not sure why this works under Solaris, but if you change the line to > read: > typeset ProductName="$1" > re-build the rpm and stuff it back in place, you should be good to go. It works on Solaris, and on Linux, because that's how ksh is supposed to behave. We've never seen this failure inside Sun. Where did your /bin/ksh executable come from? (Did you install the pdksh RPM from the Supplemental area of the SRSS image?) What does 'echo $ProductName' say in the shell you ran 'utinstall' from? I see that some of the installer scripts don't invoke ksh with a -p option. IMO that's a bug but I don't know whether it bears on this problem. Just for fun, what's in /.profile on this machine and, if the shell you ran 'utinstall' has a $ENV variable defined, what's in the file pointed to by $ENV? OttoM. __ ottomeister Disclaimer: These are my opinions. I do not speak for my employer. _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
