Re: Leading newlines in script output

[David Fifield <david () bamsoftware com>]

On Sun, Oct 31, 2010 at 11:30:27PM +0100, Djalal Harouni wrote:
> On 2010-10-03 15:45:04 -0700, David Fifield wrote:
> > On Sun, Oct 03, 2010 at 04:05:50PM +0100, Djalal Harouni wrote:
> > > When testing dns-zone-transfer and nfs* scripts I've found that some
> > > scripts that use the tab library to arrange their output, will have an extra
> > > empty line between each row when dumping the output.
> > >
> > > Current output of dns-zone-transfer:
> > > | dns-zone-transfer: 
> > > |   
> > > |   Domains      Added Targets  
> > > |   Node Names   159            
> > > | 
> > > |                
> > > | 
> > > |   DNS Records  Added Targets  
> > > | 
> > > |   A            32             
> > > | 
> > > |   MX           9              
> > > | 
> > > |   NS           4              
> > > | 
> > > |   SOA          1              
> > > | 
> > > |   CNAME        160            
> > > | 
> > > |_Total new targets added to Nmap scan queue: 365.
> > >
> > > (Other scripts are also affected).
> >
> > Sometimes scripts that use tab.lua look like they are using extra blank
> > lines because there is blank space at the ends of lines. The extra
> > blanks wrap and make it look like another line.
> Yes David this is it, the problem was in the tab.addrow() function which
> adds a complete row to the table and moves to the _next_ row. When I've
> added the 'tab.lua' support to nfs-* scripts months ago, the tab.addrow()
> function was perhaps buggy and the _next_ row was not added, but now it
> is added and included in the output.
>
> I've attached a patch to remove this _extra_ row, so an explicite call to
> tab.nextrow() is needed in order to move to the next row, this is like
> the tab.add() and tab.nextrow() combination (consistency).

I think you should do the opposite: let tab.addrow continue to call
nextrow like it is documented to do, and update the scripts that call
addrow so they don't call nextrow too. Or is there a reason that doesn't
work?

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/