[Surfraw-devel] added three elvi

[Ian Beckwith]

Hi,

On Fri, Jan 07, 2011 at 09:27:17PM -0700, Kyle Isom wrote:
> I've written a new elvi and wrote two others to update functionality in
> other elvi.

Thanks!

> I've added ddg and openports:
>     * ddg uses SSL search by default and offers a few other flags (such as
>     safe searches, and turning on javascript).

As this is better than the existing duckduckgo elvi, I've replaced
that with your version.

>     * openports covers the basic functionality of openbsd -ps but has flags
>     for every search type provide by openports.se (particularly description).

Committed. I should probably replace openbsd -ps with a pointer to
openports, what do you think?

> I also added in cablesearch, which searches cablesearch.org for leaked
> diplomatic cables.

Excellent! Someone pointed out on Reddit that, given the original
author, there should really be an elvi for wikileaks, I've been
meaning to remedy that.

http://www.reddit.com/r/programming/comments/ekesy/i_often_use_a_neat_little_program_called_surfraw/

After a brief discussion with my conscience, I decided to leave in
your mischievous comment in Local options, but it is *your* fault if
we get panicky emails :)

I saw your comment:
# for when I figured out how to parse json in surfraw...

er, yes, that would be... painful in shell.

I don't know if it would be appropriate for surfraw (I've not looked
at the API), as surfraw is all about ultimately handing a URL to the
browser, but if so, you could use a separate helper program if needed.

There isn't really a defined place for helper programs, I suppose
under ${PREFIX}/lib/surfraw/helpers or something. Seems a bit
inelegant as the elvi are in ${PREFIX}/lib/surfraw, I should maybe
have used ${PREFIX}/lib/surfraw/elvi/ originally, but I'm not changing
it again, as some people will have that directory in their path.

deblists used to get round this by having an enormous perl script
inline in the shell script, but that was a horrible idea and I was
relieved when the interface changed and that code could be removed.

The opensearch helpers live in /usr{/local}/bin, but they are at least
theoretically useful outside surfraw.

I made a few trivial changes to your code:

* cablesearch: removed w3_parse_option_hook, it was just a stub, and
  surfraw falls back to an internal version if you don't provide one.

* cablesearch: fixed header, it claimed to be openports :)

* test/Makefile.am: fixed typo, "s unonesearch" instead of " sunonesearch"

> I haven't encountered any issues with using surfraw yet, are there any
> outstanding bugs or development issues I can help with?

ooh!

Well, more elvi are always good.

You could run the test suite and fix any broken elvi it finds.  Often
you just need to fix the test, but sometimes the site has had a
gratuitous redesign and the elvi need fixing.

If you are *really* bored, you could extend the test suite, many tests
only test the basic search and don't test any of the command-line
options still work.

thanks!

Ian.

-- 
Ian Beckwith - ianb at erislabs.net - http://erislabs.net/ianb/
GPG fingerprint: AF6C C0F1 1E74 424B BCD5  4814 40EC C154 A8BA C1EA
Listening to: Orb - U.F.Orb (Limited Edition) (Disc 1) - OOBE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 237 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/surfraw-devel/attachments/20110112/a12c52ac/attachment.pgp>