Lolcate local vs global databases

[BartMassey]

Trying to create or update the lolcate database with lolcate --db ./example --create or lolcate --db ./example --locate gives an error.

For --create I get

Error: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }

Using the absolute path `pwd`/example works fine.

For --update I get

Config file not found for database ./example.
Perhaps you forgot to run lolcate --create ./example ?

Again, using an absolute path works fine.

Built from current master commit f876603, Debian Linux

[ngirard]

The expected syntax is --db <name> rather than --db <path>.
The databases are stored in either $XDG_DATA_HOME/lolcate or $HOME/.local/share/lolcate.
Do you think I should make it clearer in the documentation ?
Or do you have a particular reason for specifying your own path to Lolcate ?

[BartMassey]

I was messing around with lolcate and just wanted to put a database in /tmp to try it out. Never occurred to me that I couldn't specify a path (and absolute pathnames seem to work fine?).

I want my database to eventually be built globally, but don't have XDG_DATA_HOME set: I expect others may also. Is lolcate intended to work on Windows / other non-UNIX systems?

I guess I'd suggest having a --db-path argument that sets the root directory for the databases. This will also make the --db argument clearer. I'd make the existing argument --db-name but still allow it to be abbreviated to --db for back-compatibility and convenience.

I think there's an issue floating around for splitting the config files out from the database directory, but I forget the status of that. I'd really like that: IMHO the config files should be in /etc/lolcate and the database root should be in /var/spool/lolcate or somesuch.

[ngirard]

Is lolcate intended to work on Windows / other non-UNIX systems?

It should work on MacOS, although I haven't tested it (see #21).
Windows systems are currently unsupported (see #22).

[ngirard]

I think there's an issue floating around for splitting the config files out from the database directory, but I forget the status of that.

The configuration files are kept separated from the database files:

• the configuration files are stored either in $XDG_CONFIG_HOME/lolcate or in $HOME/.config/lolcate;
• the database files are stored either in $XDG_DATA_HOME/lolcate or in $HOME/.local/share/lolcate.

[ngirard]

I want my database to eventually be built globally
(...)
I guess I'd suggest having a --db-path argument that sets the root directory for the databases.

One big design goal for Lolcate was to make it straightforward for regular users to create and query their own databases.
I'm willing to make Lolcate usable system-wide, provided it doesn't make it more complicated for regular users to query their own databases.
In particular, I'd really want the invocation

lolcate <query>

to be always valid no matter what, because it's the simplest possible one.

Now, consider the following situation: there's both a global database named 'default' and another one, also named 'default' but belonging to user <u>. How such lolcate <query> invocation would be supposed to work then ?

[BartMassey]

Priority order should probably be --db-path argument, XDG_DATA_HOME, .local/share/lolcate, /var/spool/lolcate? This would be essentially what you have now but with an override and a fallback.

[ngirard]

So if I understand correctly, when user <u> invokes

lolcate <query>

his own "default" database would be queried because of the priority order, is that what you mean ?

In this case, what could be the correct syntax for him to query the system "default" database ?

lolcate --db-path /var/spool <query>

doesn't look fine to me

[BartMassey]

Yes (--db-path /var/spool/lolcate). If the user doesn't have a personal database specified by XDG_DATA_HOME or in .local/share/lolcate they will get the system one by default if it exists, which should cover the common case without an extra argument.

[BartMassey]

BTW, I'm not really sure which of share or spool or cache the datbases should be in. One of us should look at LSB if you haven't already. :-)

[BartMassey]

Do the lookups on a per-db-name level. So if the user says --db magic they get whichever magic database is highest priority.

[BartMassey]

You might want LOLCATE_DB_PATHNAMES environment variable or similar for the user who wants really custom lookups.

[ngirard]

BTW, I'm not really sure which of share or spool or cache the datbases should be in. One of us should look at LSB if you haven't already. :-)

Mlocate stores its data in /var/lib/mlocate/mlocate.db, so I'd be inclined to do something similar.

[ngirard]

I'd find it too complicated if regular users had to type

lolcate --db-path /var/lib/lolcate

to query the default system database.

Here's my proposal.

• when invoked by regular users (i.e. with a uid>100), Lolcate would look into $XDG_DATA_HOME/lolcate or $HOME/.local/share/lolcate for databases, as it does currently ;
• this behavior could be altered with such -S / --system-databases / --system-directory / whatever option, such as lolcate -S would look for databases in the system directory (/var/lib/lolcate);
• when invoked by system users or with elevated privileges, Lolcate would use the system directory by default.

Would you be fine with that ?

[ngirard]

Also shall we rename this thread as e.g. "Ability to use Lolcate globally" ?

[BartMassey]

I'm having a hard time imagining the case where a regular user would need to use --db-path in normal operation. If you search the four possible source directories in priority order and take the first one that has the requested database name, I think that covers most users' expectations: if they want to routinely use both local and system databases, I assume they'd choose local database names that don't conflict with the system ones. Honestly, I think most users are only going to use one or the other: on systems where there's a global database that's usually what you want, on systems where there's not you will usually want to build your own.