[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: surfraw ultimatum

On Tue, 22 Jul 2003, Thomas Smith wrote:
> On Tuesday, July 15, 2003, at 05:53 PM, I wrote:
> > I strongly believe that this is an overreaction.  Christian is willing 
> > to work with us to bring the package up to date, so there is no reason 
> > not to accept this.  I suggest that someone (I could do it) sets up an 
> > Alioth project for surfraw, so that the non-DD's who are interested 
> > can more easily contribute (using cvs or subversion).

<religious><asbestos longjohns>
Just don't *dare* to let anyone remove /usr/bin/google or I'll kill you, 
your dog and your friend's uncle's son's ex-roommate's girlfriend's aunt's 
pet hamster.

"surfraw --search-engine-to-use=google" is not an option in my book,
even though it can be aliased.

The Alioth project is a great idea, it would (aside from the main point, 
organizing bugfixes) prevent such heretical moves like the one 
above.  Surfraw provides a great convenient command-line interface to a 
zillion of search engines, however most of these engines tend to be not
used by anyone but a bunch of users.  On the other hand, damn everyone
uses google (or perhaps altavista or similar).  What about leaving 
interfaces to the few widely used search engines in /usr/bin/, and
moving aside (to /usr/share/surfraw/) the rest?  I might agree that
commands like "W", "rhyme" or "ask" are non-obvious and can cause
conflicts (name pollution), but come on, I can't think of any command
named "google" or "altavista" that would do anything else than to 
do a Google/AltaVista search.

While any seasoned admin or programmer is supposed to know where to look
for documentation, an average user is not likely to look in
/usr/share/doc/some-name-not-related-to-the-command/some-file.  If the 
command "google" you got used to suddenly stopped working, you won't know 
that a workaround can be found in /usr/share/doc/surfraw/README.Debian.

Surfraw's core functionality is just a tiny (but really convenient) alias.
There is no real difference between adding to your .bash_profile:
export PATH="$PATH:/usr/share/surfraw/"
to your .bash_profile, and adding something like:
alias surfraw='${BROWSER:-links} "http://www.google.com/search?"; `echo 
$*|sed s/foo/bar/`'
Thus, for both novice and expert users, axing /usr/bin/google is not a lot 
different from removing the surfraw package completely.

You do know how to look for documentation, people don't.  I had seen a 
friend (MSc in marketing) stumped by the task of creating an account on a 
free e-mail service, and a guy with PhD in computer science (not an Unix 
person, though) who asked for help with compiling an automake-style 
package (untar, configure, make).  Check out the "Installing from sources" 
section on http://kbtin.sf.net/ -- are these instructions enough?  
Considering from the number of e-mails I get, seems they're not.

Let's not throw hurdles at users who want to just use surfraw like it was 
intended to be used.

> So if anyone would like to start work and 
> send me surfraw patches I will be happy to quickly review them and 
> upload them, but I don't think I can fix any bugs myself for a few days.
Considering the number of people interested in surfraw, you most likely 
already received a complete set of patches.
Unless anyone says the patches are done, I can do them.

All the bugs are either trivial or already have patches, except:
#134498: surfraw: component for searching Debian mailing lists
 -- request for a new elvi
#192869: surfraw: surprized you added so many commands to /usr/bin
 -- an evil conspiracy
#201175: surfraw conflicts with the 'rhyme' package
 -- so rename the command, in either of the packages


/-----------------------\ Shh, be vewy, vewy quiet,
| kilobyte@mimuw.edu.pl | I'm hunting wuntime ewwows!
Segmentation fault (core dumped)

Reply to: