That does produce expected output (no extra blank lines). Encapsulating
the call to utdialog in $() in the utconfig script also hacks around the
problem. I'll look at adding that to the other scripts that call
utdialog until a better solution comes along.
FYI, I also discovered that by default, Ubuntu (and probably debian, but
I'll have to confirm), installs pdksh ("public domain ksh", basically a
clone of AT&T ksh) by default. I did install the standard AT&T ksh
alongside and test again (Ubuntu packages ksh93), but still got the same
extra blank line from utdialog, so I suspect it's related to a lower
level library difference and not ksh. On the other hand, the case
statement works as expected, so that at least could be attributed to a
compatibility bug in pdksh.
Thanks.
Seth
On 07/14/2011 03:45 PM, Bob Doolittle wrote:
What happens when you run the following command by hand?
% print yes | /opt/SUNWut/lib/utdialog -H YesOrNo
utreplica.ContinueNoPort 2>/dev/null
Y
%
This is the same result on Solaris and Red Hat Linux (RHEL 5.6). There
is no blank line in the output.
Make sure you redirect stderr, so you don't mix up the blank lines
before and after the prompt with the actual output.
This is a horrible hack, but a way you can collapse whitespace including
blank lines in output from a program is to do something like:
echo $(utdialog ...) | read REPLY
You shouldn't *have* to do this, however. I wonder what difference
between RHEL 5.6 and your version of Ubuntu is causing this problem? If
it's not an outright Ubuntu bug (as that ksh case-statement issue
suspiciously appears to be) I suppose it's some change that hasn't yet
made it to 5.6 that we're going to run into eventually.
-Bob
On 07/14/11 04:19 PM, Seth Galitzer wrote:
I'm doing some further debugging on this problem, and my patch from
yesterday seems to not solve the problem. It appears that utdialog
does not behave as expected in ubuntu. No matter if you choose Y or N,
the result returned to the calling function ReplyYesOrNo in config_lib
is always an empty string. To compound the problem, the putting the
return statement inside the case block simply does not work in the
Ubuntu ksh. If I use an intermediate variable replacement, I can
conclusively show that utdialog is not working as expected on this
platform.
Unfortunately, I can't debug any further because utdialog is a
compiled binary and not a script. I can see that if I run utdialog by
itself (supplying appropriate options), it returns an extra blank line
before the response. Perhaps this is due to a difference in glibc or
some other core lib? Since I can't fix the binary, what I'm going to
attempt to do next is write a script replacement for it and hope it
doesn't break anything else. As it is now, utdialog is utterly useless
on this platform.
Seth
On 07/13/2011 04:34 PM, Seth Galitzer wrote:
After a couple hours of debugging this, I finally found the problem. I'm
guessing it's a difference of ksh that ships w/ Ubuntu and that of
Solaris. Patch is below, and I've added it to my patch file.
# start patch
--- /opt/SUNWut/lib/support_lib/config_lib.orig 2011-07-13
16:15:54.598289938 -0500
+++ /opt/SUNWut/lib/support_lib/config_lib 2011-07-13 16:16:16.558289987
-0500
@@ -66,8 +66,8 @@
case "$REPLY" in
N) return 1;;
Y) return 0;;
+ *) return 2;;
esac
- return 2
}
UTLIBDIR=/etc/opt/SUNWut/basedir/lib
# end patch
Basically the ReplyYesOrNo function, sourced from
/opt/SUNWut/lib/support_lib/config_lib has a redundant return statement.
My assumption is that the outer return statement was meant as a fallback
if neither Y nor N was entered, and that Solaris' ksh handles it by
returning directly from within the case statement, terminating the
function. With Ubuntu's ksh, the inner return does not break out of the
function, just from the case statement, so the outer return always gets
executed. The function itself does not permit any reply other than Y or
N, so the fallback response should never be triggered. In any case, the
syntax for Ubuntu's ksh is to have the default clause within the case
statement itself.
FYI, I have learned that debugging ksh can be quite a pain. Including
set -x in Ubuntu's ksh does not follow down into functions. I had to add
'typeset -ft $(typeset +f)' to the DoConfig function before I got
sufficient debugging info to find the source of the problem.
Cheers.
Seth
On 07/13/2011 12:00 PM, Bob Doolittle wrote:
On 07/13/11 12:54 PM, Seth Galitzer wrote:
I've been generally following the howto in the wiki for 4.2 on Ubuntu
9.10 (and the addendum for 10.04), making adjustments and documenting
as I go. Everything is pretty comparable for the newer versions. A
couple of steps are no longer necessary (including patching the kernel
modules), and I hacked the patch file a bit to work with new system
files. Only one step has me concerned, and I don't know if it's
because of Ubuntu or new behavior from SRSS tools.
When I run utconfig after running utadm for the first time, it doesn't
produce any output or prompt me for any input. Is this normal for 5.2?
No, this is not normal. Offhand, I can't imagine why it would fail in
such a manner, but as it's a shell script it should be easy to diagnose
by instrumenting with a "set -x".
-Bob
Is it better at figuring out application paths? Or did it silently
fail for some reason? Is there a config file to manually edit or check
to verify that utconfig did anything?
Really, I'm just checking to see how well SRS runs on Ubuntu, as
that's what we use for most everything else here. My next test was
going to be on CentOS 6. Is there documentation for that somewhere?
I'd be happy to provide my notes and patches to whoever is maintaining
the Ubuntu how-tos on the wiki. Feel free to email me off-list if
you're interested.
Thanks.
Seth
--
Seth Galitzer
Systems Coordinator
Computing and Information Sciences
Kansas State University
http://www.cis.ksu.edu/~sgsax
[email protected]
785-532-7790
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
