[Nikto-discuss] Bug: Nikto eating input from non-tty stdin
Serge van den Boom
svdb at madison-gurkha.com
Tue Apr 19 06:18:50 CDT 2011
On Tue, 19 Apr 2011, dave at cirt.net wrote:
>>> The quickest way to resolve this may just be to add a -batch switch to
>>> disable interactive features, though then you could only quit via CTRL+C.
>> I suspect that most users would not find out about this switch until
>> things have gone wrong, and it may cost them a lot of time in the
>> meantime. There is no reason why Nikto would need to read from stdin
>> when it is not a tty, so a simple isatty() check would be enough.
> Good point; though of course it may be a user requirement to use the
> interactive features whilst doing a loop; hence testing is needed on
> at least the big 3 platforms (Windows, Mac and Linux).
If you're running Nikto from within a loop in which stdin is redirected,
then you won't have access to the interactive features regardless of how
Nikto treats stdin.
And if you run Nikto from within a loop without redirecting stdin (such
as the "for TARGET in ..." construct), then stdin will be a tty,
isatty() will return true, and you can use Nikto's interactive features
So running within a loop makes no difference.
But if you really do want to be able to read interactive keyboard
commands from something which is not a tty -- and I don't see a
practical use for this -- then you could always do it the other way
around: Add a command line option to force interactive mode (as Bash' -i
> For now the only work around I can suggest is to avoid using stdin to
> pass stuff as you're doing at the moment (using something like the for
> loop I suggested earlier).
Starting nikto with "< /dev/null" would do the trick here (on Linux),
while allowing the use of the "while read" structure.
Or even "< /dev/tty", which will keep the interactive features working.
More information about the Nikto-discuss