[Surfraw-devel] surfraw

[Kevin Kreamer]

--=-=-=
Content-Transfer-Encoding: quoted-printable

Ian Beckwith <ianb@nessie.mcc.ac.uk> writes:
> On the namespace issues, I am happy to leave things as they are,
> although I suspect it is an issue that will keep coming up, especially
> if we add lots more elvi.

Well, we can't leave things *exactly* as they are (cf. #192869 and
#201175).  So, the question becomes, how best to change it?  And that
is really a question of our relative values for:

1) ease of setup for our users.
2) ease of continued use for users.
3) consistency with other elvi.
4) the ability to install surfraw at the same time as other unrelated
packages.
5) ease of continued maintainance for us.

[ Fair warning: the following is a bit long. ]

The rough consensus on -devel was to move all the elvi to another
directory to be added to the user's path (as far as I could tell).
That is the most obvious course of action, but as I've thought more
about it, I'm not sure it's entirely correct.  The argument that
Thomas has given is that it hurts #1 up there, as the user would have
to take the time to add it.  This argument is not convincing to me, as
presumably surfraw is going to be used to be used by people
comfortable with the command line and therefore comfortable with
adjusting their $PATH.  This solution works well for #3 and #5.  It
seems to work well for #2 and #4, but at second glance, it does not.
You see, we actually have two namespaces to worry about here.  The
first (which it does solve) is for files on the filesystem; the second
is for commands that are run when a given command is typed into the
command line.  It seems to me that this solution does not, in fact,
solve #4 at all. If I have surfraw and rhyme both installed, what gets
run when I type in 'rhyme'?

Notice that this is not the first time conflicts with other names have
come up with surfraw.  Also notice that the practice so far has been
to prefix the command with 's' (see, translate & stranslate, linuxdoc
& slinuxdoc, and swhois).  The major issue I see with this scheme is
that the conflict must first occur, and then the name is 'fixed'.
Well, that hurts #2, because the names of the commands keep changing
on me as a user.  It also obviously hurts #4 until it is fixed and #5
in fixing it.  It's also terribly inconsistent (#3).

However, if we pre-emptively prefix all the commands (say, with 'sr'),
then some of the objections go away.  It's a consistent solution (#3),
which I like because the commands won't change on me later down the
road.  It solves #4 because there's little chance of a command being
installed that starts with 'sr' (which is why I didn't suggest just
's'... there's lots of commands that start with 's').  It's easy to
maintain (#5) and there's no initial setup for our users (#1).  Aha,
you say, but what about #2?  Well, at first glance, our users would
have to type in two extra characters (which isn't too bad in and of
itself).  However, if you keep in mind command line completion, they
might usually type less.  In the best cases, they can type in 4 chars
('sr' thinking "I want to search for..." 'g' "... google" and then
<tab> to complete it).  Additionally, with this scheme, we can also
support a 'surfraw google whatever' for those who want to use surfraw
that way (helpful for new users who haven't read the docs and would
solve #173714), and even support putting the originally named elvi in
/usr/bin/elvi (or wherever) so that those who really want to futz with
their $PATH and call it using just 'google' can do that too.
=20
In any case, namespace issues shouldn't keep the other bugs from
being fixed, so could we do that interim upload that Thomas was
talking about?

Kevin

P.S.  My alioth account name is kkreamer-guest (for the cvs access).

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQA/R5gUS61jHDsCLJIRArsgAJ40faCxnpBFNmmby+yzEC01kBGDiwCeOOFv
oPzpFte9DlcCVf9yMKlgcTc=
=SNHj
-----END PGP SIGNATURE-----
--=-=-=--