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.
</asbestos></religious>
"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.
Whee!
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
Regards,
1KB
/-----------------------\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\-----------------------/
Segmentation fault (core dumped)
