Re: zenmap as root error

["Guilherme Polo" <ggpolo () gmail com>]

2008/4/1, João Medeiros <ignotus21 () gmail com>:
> On Tue, Apr 1, 2008 at 11:39 PM, Guilherme Polo <ggpolo () gmail com> wrote:
>  >
>  > 2008/4/1, João Medeiros <ignotus21 () gmail com>:
>  >  > On Tue, Apr 1, 2008 at 11:21 PM, Guilherme Polo <ggpolo () gmail com> wrote:
>  >  >  > 2008/4/1, João Medeiros <ignotus21 () gmail com>:
>  >  >  >
>  >  >  > > On Tue, Apr 1, 2008 at 10:52 PM, Guilherme Polo <ggpolo () gmail com> wrote:
>  >  >  >  >  >  But, for PyGtk 2.8 and earlier I would suggest doing this in a
>  >  >  >  >  >  different manner (and much simpler and less error-prone):
>  >  >  >  >  >
>  >  >  >  >  >  try:
>  >  >  >  >  >     import gtk
>  >  >  >  >  >  except ImportError, e:
>  >  >  >  >  >     print e
>  >  >  >  >  >
>  >  >  >  >  >  For PyGtk 2.10 and newer, ImportError is actually a warning so the
>  >  >  >  >  >  code changes a bit:
>  >  >  >  >  >
>  >  >  >  >  >  import warnings
>  >  >  >  >  >  warnings.filterwarnings('error', module='gtk')
>  >  >  >  >  >  try:
>  >  >  >  >  >     import gtk
>  >  >  >  >  >  except Warning, w:
>  >  >  >  >  >     print w
>  >  >  >  >  >  warnings.resetwarnings()
>  >  >  >  >  >
>  >  >  >  >
>  >  >  >  >
>  >  >  >  > I think that just display the an eventually warning is not enough. We
>  >  >  >  >  have to leave segfault.
>  >  >  >
>  >  >  >  If this Warning happens, it implies the gtk engine couldn't start and
>  >  >  >  the app wouldn't run anyway (or could try and segfault). Also, you
>  >  >  >  could just call exit after your print that message, it was just a
>  >  >  >  correct template on how to proceed when importing gtk fails.
>  >  >
>  >  >
>  >  > Hum, sorry if I'm wrong, but if I just call exit in a warning
>  >  >  exception the programing will exit with any warning. Maybe some
>  >  >  warning does not cause segfault.
>  >  >
>  >
>  >  You could then alternatively catch ImportWarning, but this one I
>  >  haven't tested. The problem with your "solution" was already pointed
>  >  by Fyodor, setting a wrong DISPLAY will bypass your solution and the
>  >  segfault will still happen.
>  >
>  >
>  >  >
>  >  >  >
>  >  >  >  > By this way we have to check if the waring is
>  >  >  >  >  associated to display too.
>  >  >  >
>  >  >  >  Why ? Just checking for DISPLAY, like you proposed, doesn't solve this.
>  >  >
>  >  >
>  >  > Because of what I say above I think we have to check display
>  >  >  condition. Checking the if DISPLAY var is set and the system is
>  >  >  *nix-like the problem is solved. I have just tested in my linux
>  >  >  machine few minutes ago.
>  >  >
>  >
>  >  Gtk already checks for dispaly.
>  >
>
>
> I'm just trying to say to you that you have to check if the warning is
>  associated to "Can't open display". Because this is not a import
>  problem. I think this solve the problem. Good lucky.

It is not directly a import problem, but it triggers a import problem
(in the version I use at least, 2.14), but may not trigger in another
version, that is why I said this is untested. Also, since it triggers
this importwarning here, it may not be possible to directly check for
"Can't open display".

It gets pointless to discuss this if you can't accept a more correct
solution than yours. Anyway, you seem to have some problem to believe
in something besides your solution, so the best I can do is point some
links that apply this solution I mention or is at least very similar:
http://live.gnome.org/PyGTK/WhatsNew210,
http://www.koders.com/python/fid0D14585D38F1C6DCC20D514866E2B0D7F11E5C21.aspx?s=warnings.filterwarnings('error'%2c+module%3d'gtk')#L56,
http://www.google.com/codesearch?hl=en&q=+warnings.filterwarnings+%27error%27,+module%3D%27gtk%27+show:6ohMnsUyTO0:Pflu6ziglk8:TMCLtmnvefc&sa=N&cd=3&ct=rc&cs_p=https://www.lagaule.org&cs_f=pipermail/commits/2007-October.txt.gz#first

Also, "Good lucky" or "good luck" ? Please, be less ironic.

>  Att, João Medeiros.


-- 
-- Guilherme H. Polo Goncalves

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