search

projectdiscovery / shuffledns

MassDNS wrapper written in go to enumerate valid subdomains using active bruteforce as well as resolve subdomains with wildcard filtering and easy input-output support.
https://projectdiscovery.io
GNU General Public License v3.0
1.28k stars 183 forks source link

Add Progressbar to show program progress #5

Open jaikishantulswani opened 4 years ago

jaikishantulswani commented 4 years ago

Hi @Ice3man543 Its not an issue. But if it would have a switch or default with -verbose flag to show Progress Bar so that user can know how much entries are processed.

Regards,

Ice3man543 commented 4 years ago

@jaikishantulswani thanks for the issue. We are not picking it up as of now but will add it later asap!

mzpqnxow commented 1 year ago

I'll add to this issue even though it's not a progress bar ...

The way that I currently use massdns, for example- a message queue from an HTTP API to a worker that wraps it. Because the caller (and web UI) poll for a meaningful statis, it's helpful to have structured (or at least parsable) real-time "status" output at some interval- NDJSON, one line per-second is good

I submitted this simple PR to massdns (and a similar one to masscan) to facilitate this with both tools- it emits a line of NDJSON with some basic runtime metadata

I'm less interested in an ETA and more interested in having some basic info about the runtime status, as opposed to "yes, it's still running", "it's" done, or "it exited with a non-zero exit code"

Something like passthrough of massdns output would be fine for my purposes to stderr, stdout, or even a named pipe. Ideally, both passthrough of massdns and shuffledns runtime data would be emitted

Some data points that would be nice- total requests emitted, total runtime, total requests remaining, total number of results by status code, etc. I'm not familiar with the codebase, though and realize that shuffledns may not have this info handy, because of its use of massdns for some or most of the resolution; hence the suggestion of invoking massdns with the flag from the PR I mentioned and then just passing the massdns stderr through to shuffledns stderr, for the user to parse themself. That way it would just be an opaque blob to shuffledns and no parsing logic needs to be added

In either case, it should not replace the output file(s) with the final results- it would just be additional output separate from processed results

@Ice3man543, I don't know why you felt this request should be deferred (nor am I questioning it) but would you be more open to something like what I'm describing, which doesn't require drawing on the screen or tracking state?

I would be happy to submit a PR if you philosophically support the idea, if I can find the time. Similar to the way it's implemented in massdns and masscan, it would be an optional flag, to not disturb other users of the tool

Hopefully I described this somewhat clearly :)

Thanks for your work on this project + your patience and the time spent handling feature requests- regardless of whether they're implemented