Nulls in output...

[geneb]

I run a series of jobs via cron and their output is captured and emailed
via the cron daemon (Linux host).

The output from the Pick jobs are filled with nulls as the first and
sometimes second character of each line. They appear as "^@" when reading
the email via Alpine, but the nulls cause problems when the emails are
being read via Outlook - no output appears in the email beyond a lot of
blank lines.

Is there any way to get D3 to stop prefixing lines with nulls?

tnx.

g.


--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

[fwinans]

linux  {also cgwin, if you had been on d3/nt}  can delete those null chars with
   /usr/bin/tr   -d   '\000'   in your pipe string.

Example:  at bash "#" prompt,       /bin/echo   -en  'A\000B\000C'  |  od -c 
shows
      0000000   A  \0   B  \0   C
      0000005

but      /bin/echo   -en   'A\000B\000C'  |  /usr/bin/tr   -d   '\000'   |  od  -c
shows
     0000000   A   B   C
     0000003
ie, the null bytes got removed from the test string.
Note some  d3 verbs like  list-labels   use null padding at end each line...
You might want to strip out  formfeeds too;   /usr/bin/tr   -d   '\000\012'

Frank
On Thursday, January 15, 2015 at 7:46:06 AM UTC-6, geneb wrote:

<snip>

[geneb]

On Thu, 15 Jan 2015, fwinans wrote:

> linux {also cgwin, if you had been on d3/nt} can delete those null chars
> with
> /usr/bin/tr -d '\000' in your pipe string.
>

Thanks Frank, I'll give that a shot. I just wish there was a way to force
D3 to knock it off. :)

[Tony Gravagno]

Look at the D3Ref for the TERM command which includes this juicy tidbit:

term tw,td,ls,ld,fd,bs,pw,pd,tt {(options)}

ld : Linefeed delays is the number of null characters to output after each line feed. This is typically set to 0.

If that doesn't help, perhaps an exchange with Rocket D3 Support would.

Best,

T

[geneb]

On Thu, 15 Jan 2015, fwinans wrote:

> The nulls might be due to nonzero linefeed or formfeed delay in TERM;
> try doing term ,,,0,0 earlier in the tcl session, see if it helps.
> (untested)
>
I'll give that a shot, thanks!

[geneb]

On Thu, 15 Jan 2015, Tony Gravagno wrote:

> Look at the D3Ref for the TERM command which includes this juicy tidbit:

> term tw,td,ls,ld,fd,bs,pw,pd,tt {(options)}ld : Linefeed delays is the number of null characters tooutput after each line feed. This is typically set to 0.

> If that doesn't help, perhaps an exchange with Rocket D3 Support would.
> Best,T
>
>

The nulls are appearing right out of the box (prefixing the lines in the
login prompt), so I don't know if that will work - but I'm going to try
it.

tnx.

[fwinans]

oops!  formfeed is octal \014   not \012  as I had written.

These nulls are explicitly coming from d3, they are not due to a linux
stty  setting.  And  the verb  term ,,,0   seems to stay in effect even
after you do   OFF  and as you are being prompted for userid and password,
but then it reverts back to term ,,,1  even if you remark out the TERM-TYPE
line {if any}  in your chosen item of the users file, so it's pretty hard to avoid all
possibilties of seeing a null in a 'capture'  file  like from doing  d3  > /tmp/foo </tmp/sysin

Remember that although  null is  \000 in a   tr  command of linux,  it would be
   \x0   in a sed command.   Also, in sed, suggest the form  's/\x0//g'  in case one 'line'
of session capture data has multiple nulls for some reason.
Your mail reader really hates nulls, but  you're going to see a lot of  \a  {bell, control-g} and
escape char in each session, plus whatever control chars your TERM settings in d3
dictate for cursor movement, text highlighting, etc.

 
Frank

[geneb]

On Fri, 16 Jan 2015, fwinans wrote:

> oops! formfeed is octal \014 not \012 as I had written.
>
> These nulls are explicitly coming from d3, they are not due to a linux
> stty setting. And the verb term ,,,0 seems to stay in effect even
> after you do OFF and as you are being prompted for userid and password,
> but then it reverts back to term ,,,1 even if you remark out the TERM-TYPE
> line {if any} in your chosen item of the users file, so it's pretty hard
> to avoid all
> possibilties of seeing a null in a 'capture' file like from doing d3 >
> /tmp/foo </tmp/sysin

I tried the term ,,,0,0 as you'd suggested and that eliminated all the
nulls that were in the file except for a few at the very beginning.

Thanks!