We've seen similar issues with output of "nexec"'ed commands with App server ver 6.3 and 6.3.3. We believe the issue we are having is only when going against some older (6.2.x) agents but it's possible the problem is present with newer agents too.
We see out like:
(that's ctrl-D ctrl-H ctrl-H at the start of the output) from commands like:
"find /opt -type d -name prod"
We appear to only have a problem when running nexec's from within jobs. If we run those same nexec commands manually in nsh we don't see the problem.
We've had a ticket (9436) open on it for about a month now. Does not look to be any progress yet.
Message was edited by:
I suppose it's comforting to hear I'm not the only one seeing it :). Have you tried upgrading your agents? I know that I only see this problem on specific servers. I had thought it was against an agent of the same version, but I might be wrong. I'll take a look at the case you have open and make a note that I'm seeing it as well and hopefully we can get at least an official in-house reproduction of the issue and fix.
I have seent this behavior before on 6.2.x. To work around it, you can strip out all control characters (including newlines):
nexec -e somecommand | tr -d '[:cntrl:]'
This has helped somewhat, but I am still seeing ^D characters in my output:
SYSTEM_OS=`nexec -e uname -s`
echo "OS was $SYSTEM_OS"
SYSTEM_OS=`nexec -e uname -s | tr -d '[:cntrl:]'`
echo "OS is $SYSTEM_OS"
produces this output:
Info 01/06/2006 13:31:49 OS was ^D SunOS
Info 01/06/2006 13:31:49 OS is SunOS^D
I find it strange that on the 2nd one it puts the ^D at the end of the variable. Do you know how to get rid of the ^D?
are you executing these NSH jobs/commands from a windows appserver or on windows agents? i know that this is a problem when running nsh commands and trying to store the output to a variable in these scenarios.
instead of specifying the POSIX character class for control chars, you should use the ascii key codes for the control characters that you're seeing instead.
the problem is that the posix character classes are not well defined. (which is oxymoronic, considering that posix and IEEE compliance standards are supposed to be well-defined) and depending on what version of tr you're using you may or may not be able to use them. i believe that nsh tr supports these, but again you're better off specifying the exact control characters that you want to eliminate.
here's a couple of handy links to ascii key code tables:
If you're running at least a 6.3.1 appserver, try adding the
following option to the nexec command:
nexec -n -e uname -s
-n is a new option starting in 6.3.1 which tells the nexec command not
to deal with stdin.
I think what's happening is some of the control characters that the nexec
command sends across to the agent are getting interpreted as stdin by
the agent. The agent then displays them on stdout which gets funneled back
to the client as stdout. It's basically a timing thing which is why it
If you know your command is definitely not going to be interactive (as
would be the case with all NSH Script Jobs), try the -n flag and see
if that helps.