klocaldomainurifilterhelper (Re: Ctrl+O in Konq)
David Faure
faure at kde.org
Thu Sep 23 11:50:31 BST 2004
On Thursday 23 September 2004 12:00, Thiago Macieira wrote:
> David Faure wrote:
> >This change basically breaks detection of unknown hosts for me.
> >Typing "ls" in konqueror goes to http://ls (instead of going to the
> > default search engine), because "klocaldomainurifilterhelper ls" returns
> > 0 (no error), since h_errno == NO_ADDRESS.
> >
> >Can you either revert or find a way to detect the case you mention more
> > accurately? Thanks.
>
> That's because "ls" *does* exist:
Not as a host.
> It's the top-level domain for Lesotho.
But you can't open a webpage for a top-level domain, can you? The point of
this "local domain" test is to look for hosts in the local domain...
Is there a way to look for an actual host only?
> If you had tried "cp", you wouldn't have the same result.
Indeed. Wow, confusing :)
$ klocaldomainurifilterhelper cp
ent=(nil), h_errno=1 NO_ADDRESS=4 returning 1
$ klocaldomainurifilterhelper ls
ent=(nil), h_errno=4 NO_ADDRESS=4 returning 0
OK, then I withdraw my request for removing the NO_ADDRESS test, "ls" is a really
border case.
I got confused because I looked into this because of the Ctrl+O ("file in $HOME")
issue, but now I see it's different (if the file has an extension, the localdomainurifilter
doesn't kick in at all, so it's in fact another issue, the wrong current directory. I'll look
at that now). Sorry for the mixup.
Thanks for the infos.
--
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kfm-devel
mailing list