Mailing List Archive

On Wed, 28 Oct 1998, Fabio Coatti wrote:

> I've noticed that
>
> gpg --list-keys name
>
> shows only the first match for "name", even if I've more than one key in my
> keyring that has "name" somewhere.
> Is this the correct behaviour?

Personally, I find this behavior somewhat annoying. I wouldn't even
notice it if pgp* didn't do the opposite. Had I more time, I'd work on
fixing it but for now, just chalk me up as another complainer. :-)

C=)

--------------------------------------------------------------------------
Heuer's Law: Any feature is a bug unless it can be turned off.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
Early bird gets the worm, but the second mouse gets the cheese.

This is the biggest complaint I hear from people when I talk to them about
gpg.

On Wed, 28 Oct 1998, Caskey L. Dickson wrote:

> On Wed, 28 Oct 1998, Fabio Coatti wrote:
>
> > I've noticed that
> >
> > gpg --list-keys name
> >
> > shows only the first match for "name", even if I've more than one key in my
> > keyring that has "name" somewhere.
> > Is this the correct behaviour?
>
> Personally, I find this behavior somewhat annoying. I wouldn't even
> notice it if pgp* didn't do the opposite. Had I more time, I'd work on
> fixing it but for now, just chalk me up as another complainer. :-)

Kirk Fort <kirk@patrohn.com> writes:

> This is the biggest complaint I hear from people when I talk to them about
> gpg.

And the first time I see it here on the ML; I only new that my brother
complained about it. Frankly, I forgot that I have to fix the
behaviour :-( You will notice it on the TODO list in th next release.

BTW, I need a clever algorithms to store strings in a DB and do
a substring search. I don't wan't to do a sequentiell search, but I
doubt that there is any other way (without building an index which is
not good because I have to insert many new items - or use a overflow
list until the next index run?).


Werner

On Fri, Oct 30, 1998 at 07:09:37PM +0100, Werner Koch wrote:
> BTW, I need a clever algorithms to store strings in a DB and do
> a substring search. I don't wan't to do a sequentiell search, but I
> doubt that there is any other way (without building an index which is
> not good because I have to insert many new items - or use a overflow
> list until the next index run?).
I have not looked into source, maybe you just need to use clever *search*
algorithms?

--
Mike

On Fri, Oct 30, 1998 at 07:09:37PM +0100, Werner Koch wrote:
> BTW, I need a clever algorithms to store strings in a DB and do
> a substring search. I don't wan't to do a sequentiell search, but I
> doubt that there is any other way (without building an index which is
> not good because I have to insert many new items - or use a overflow
> list until the next index run?).

How about a btree? They work also on disk.

Frank

On Fri, 30 Oct 1998 21:37:58 +0100 "Frank J. Beckmann" wrote:
> On Fri, Oct 30, 1998 at 07:09:37PM +0100, Werner Koch wrote:
> > BTW, I need a clever algorithms to store strings in a DB and do
> > a substring search. I don't wan't to do a sequentiell search, but I
> > doubt that there is any other way (without building an index which is
> > not good because I have to insert many new items - or use a overflow
> > list until the next index run?).
>
> How about a btree? They work also on disk.

Good idea. The BSD db-library provides a BTree-interface.

David
--
David Frey (B98D36A9) = 51F35923114FC864 7D05FF173C61EFDE
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer