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





_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users

Reply via email to