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