Feature request: make it more scriptable either by limiting choice to the first or enabling exact name matching

[gfarrell]

I wrote a script for khard so I can use it easily with Rofi (mimicking the functionality I used to have in Alfred when I was on macOS). The problem with this is that sometimes there are two contacts with names which cause a collision (e.g. my house in France is called "France", and I have a friend with the last name "Frances"). This causes my script to hang as khard wants interactive input. I've tried adding the UID into the list and then just selecting that with awk, but only a short UID is printed, so there are still multiple results when using khard show "uid:XXX".

I can think of three ways of making khard more scriptable:

1. add an exact-match mode to the search query where the string name:France can only match the full name /^France$/;
2. complicate (1) by adding regex syntax, supporting queries like the following: name:/^France$/;
3. allowing the user to specify a --first flag which just picks the closest match (khard show --first "name:France").

In fact, to make this completely scriptable, (3) is always necessary as two records might have the same names, but it's unlikely.

I'm happy to implement this and open a PR with (a) a bit of input on the best option; (b) a pointer as to where to start in the codebase.

[scheibler]

Did you try to use the query syntax?

From the docs:

--

The query language allows the user to search for contacts where a specific term matches in a specific field of the contact. When searching for foo there might be two contacts that match, because one is called "Foo" and the other has an email address containing "foo":

$ khard list foo Index Name Email 1 Bar [email protected] 2 Foo [email protected]

But when searching for name:foo or emails:foo one would only find one of these each time because "foo" only matches in these specific fields of the contact.

The available fields are the same as in the YAML format for contacts (an empty YAML template can be seen with khard template). Case does not matter, all filed names will be converted to lower case. For field names with spaces (like "Formatted name") the spaces have to be replaced with underscores (like in formatted_name). And the five name related fields "Prefix", "First name", "Additional", "Last name" and "Suffix" are not available, but a simple name: query is possible which will search in any name field (including nicknames and formatted names).

--

If your house isn't mentioned in the name field, something like khard show name:france should work. I'm aware, that's not the perfect solution for your issue but maybe it's a suitable workaround for now?

Alternatively why don't you search for "frances" directly? Or maybe you could support the interactive part of khard in your script like khard itself tries to do in the add-email subcommand used by email clients like mutt?

I'm thinking aloud - just ignore, if you've ruled that out already.

[mschilli87]

@scheibler

Did you try to use the query syntax?

The OP literally contains the exact query using the query syntax:

1. add an exact-match mode to the search query where the string name:France can only match the full name /^France$/;

The way I understood it, the Friend has 'Frances' as the name and the house has 'France' as the name. So the query syntax (as-is) won't help.

@gfarrell even suggested changes to the query syntax that would solve the give use case:

2. complicate (1) by adding regex syntax, supporting queries like the following: name:/^France$/;

[gfarrell]

Hi @scheibler and @mschilli87 :

As per my original message, @mschilli87 is correct: searching for name:France brings up both the house in France and the friend Frances. In this instance name:France doesn't help.

[lucc]

@gfarrell can you provide two (reduced and anonymized) vcards so that we can reproduce that? We could start by writing a test for the problem that name:... seems to search in names and addresses. Because it looks to me as if we have two things here:

1. bug report: name:France matches an address
2. feature request: make khard more script able, by some means

[d7415]

1. bug report: `name:France` matches an address

My understanding is that the contact with the French house has the name "France" so that would a naming issue, not a bug. (It's a perfectly valid name, but I think that's caused some confusion in this thread)

[gfarrell]

@lucc: as per my original post:

The problem with this is that sometimes there are two contacts with names which cause a collision (e.g. my house in France is called "France", and I have a friend with the last name "Frances").

This is not a bug report, as @d7415 has pointed out. It’s also the second time this issue has been misinterpreted but I’m not sure what else I can do to make the text clearer.

feature request: make khard more script able, by some means

As I wrote originally, I am happy to implement this improvement and have suggested how it might be done, but am simply waiting for some pointers from those more familiar with the khard code base as to what the best way in would be.

[lucc]

Well I did not expect a house to have a vcard with a name on its own. Nevermind.

In #189 I have proposed a --no-confirm or --assume-yes option. I think all relevant code that is affected by such options is in the khard.helpers.interactive module. These two suggestions are related to the confirm function. Here we are concerned with the select function. For this a --last or --select-none option might also make sense

I would like to find a small set of options that covers as many cases as possible in order to keep the interface "uniform". So more suggestions for good options and discussion is very welcome before we start coding. I imagine the option to be toplevel for khard not only for khard show. We could also add this as a config option.

For the actual implementation we have to look at khard.helpers.interactive to implement two versions of these functions or add optional arguments.

For the command line options we have khard.cli. For the config parsing we have khard.condig and the specification file khard/data/config.spec.

[lucc]

To really answer your question: I would be happy with PRs for a more scriptable interface. There is also a whole project about this: https://github.com/scheibler/khard/projects/1

I have not thought about how to implement it exactly so you can ask for more specific pointers if you have questions. I am also happy to help discussing the design first.