mailing list archives
Re: Script suggestions
From: Djalal Harouni <tixxdz () opendz org>
Date: Sun, 4 Dec 2011 17:25:14 +0100
On Sun, Dec 04, 2011 at 04:07:19AM -0500, Patrick Donnelly wrote:
On Mon, Nov 28, 2011 at 12:43 PM, Duarte Silva
<duarte.silva () serializing me> wrote:
On Monday 28 November 2011 00:52:35 David Fifield wrote:
On Sun, Nov 27, 2011 at 10:34:44PM +0000, Duarte Silva wrote:
The script option may be specified without arguments. So if you could
take it as an example I guees it would make your live easier ;)
--script requires an argument. You may be thinking of -sC (which is
really the short option -s taking the argument "C" in disguise).
It's possible to have options that take optional arguments, but I don't
think we should because it works in a suprising way. It requires you to
use '=' instead of a space after the option.
Then, it seems the two options, -scS (no arguments) and --script-suggest (same
arguments as --script) are viable options. As I come to think about it, this
way is even better.
Maybe what we really need is an option which allows the user to pass
directives to NSE. For example:
possibly in some sort of option=argument format. I could see
--script-updatedb being replaced with a directive.
I also think that we need some arguments/directives to control NSE
We should try to define the best approache to take. Currently this is the
list of options that affect directly NSE's behaviour:
o Others that use --script-args like the 'newtargets' stuff.
o We can also count the 'script suggest' and 'script force' features ...
IMHO most of these features are related to NSE behaviour more than scripts
or Nmap. Another feature is the possiblity to control how NSE output is
reported, especially for large networks, we could add an argument to let
NSE report results as early as possible (to not concatenate data).
The '--script-directives' seems currently the best proposed approache,
at least for me. It should handle any new NSE feature that can not
be done in the '--script-args' or '--script'.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/