Nmap Development mailing list archives

Re: Leading newlines in script output


From: Djalal Harouni <tixxdz () gmail com>
Date: Sun, 31 Oct 2010 23:30:27 +0100

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).

With this patch nfs-* scripts output will be ok, however
dns-zone-transfer needs an other simple patch (it's attached).


Pls David note that tab.addrow() is used only in my code, so I think
that it will be ok to commit these patches.

-- 
tixxdz

Attachment: tab_addrow.diff
Description:

Attachment: dns-zone-transfer-tab.diff
Description:

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

Current thread: