Zenmap was only showing the first line of @arg nsedoc entries, since it
was capturing the contents with a regular expression, which ends at the
first newline. Fixed by simply returning the entire contents with the
first word (the name of the arg) stripped off.
When the dialog is closed by the user clicking the X, rather than a
button in the dialog, the dialog doesn't exist anymore, so we can't
simply hide and later re-present it.
This strange error happens when canceling a "Print to File" operation on
Windows:
Traceback (most recent call last):
File "zenmapGUI\MainWindow.pyo", line 831, in _print_cb
File "zenmapGUI\Print.pyo", line 156, in run_print_operation
GError: Error from StartDoc
The web seems mostly silent on this error, and I can't guess at the
cause. Let's ignore the error as it seems to be harmless.
Reported by Imre Adácsi.
http://seclists.org/nmap-dev/2012/q4/161
There should be better error handling here in general, but an empty
string is something that Nmap can legitimately emit.
http://seclists.org/nmap-dev/2012/q2/876
We checked for OSError so that we could give a useful custom error
message on ENOENT. But on Windows, it is a WindowsError, which is a
subclass of OSError.
An important side effect of this change is the move the
--with-included-loaders flag from gtk2 to gdk-pixbuf2. This upstream
change:
http://git.gnome.org/browse/gtk+/commit/configure.in?h=gtk-2-24&id=cb29d2770714943af7b488a6a94f1f37b7466c8f
means that --with-included-loaders no longer has an effect when given to
gtk2's configure. This caused dynamic loaders to be searched for under
my /Users/david/macports-10.5 installation directory, which isn't
present after installing from the .dmg package.
Here's an report of a hang caused by the missing loaders:
http://seclists.org/nmap-dev/2012/q2/370
This restores code removed in r28342, which rewrites sys.path to include
the directory in which the Zenmap modules are installed. This is needed
to run the program without changes to PYTHONPATH when the installation
directory is not among the Python interpreter's default search paths.
(/usr/local/lib/python2.7/site-packages/ or a user's home directory are
common cases.) A difference is that now we make sure that the directory
we are adding is not writable by any other users, to avoid installation
mistakes like Debian bug #663217.