Bug#999488: plocate: updatedb: cannot prune whitespace-containing directories / paths

[Dmitry Alexandrov]

Package: plocate
X-Debbugs-Cc: d...@gnui.org
Version: 1.1.13-1
Severity: normal

Dear developer,

as you find it okay to break backward-compatibility with mlocate <https://bugs.debian.org/999487>, let me suggest you a thing, that is definitely worth being broken:

a *very* unorthodox handling¹ of arguments to -n / --add-prunenames and -e / --add-prunepaths by updatedb(8), that prevents users from specifying whitespace-containing filenames here.

Instead, it seems to be reasonable to stick by the simplest approach possible, where a switch accepts a single argument, and to specify multiple values, one have to repeat it:

$ updatedb -l no -o "$HOME/.cache/plocate.db" -U "$HOME" -e "$HOME/.local/share/Trash" -e "$HOME/various useless stuff"

Support for repeated switches is already here, so all what is to be done is to stop splitting their arguments.

--
¹ For anyone unaware: they accept a single argument, which is expected to be a whitespace-separated list of filenames. Can anybody suggest any other util, that has the same inteface?

-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)

[Steinar H. Gunderson]

severity 999488 wishlist
thanks

On Thu, Nov 11, 2021 at 11:19:47PM +0300, Dmitry Alexandrov wrote:
> as you find it okay to break backward-compatibility with mlocate
> <https://bugs.debian.org/999487>, let me suggest you a thing, that is
> definitely worth being broken:

It sounds pretty harsh to break a feature used by even the default
configuration. I do agree it is problematic not to support pruning filenames
with spaces in them, though; how would you feel about escaping them in the
configuration file, and then a flag like --add-single-prunepath that does no
splitting?

/* Steinar */
--
Homepage: https://www.sesse.net/

[Dmitry Alexandrov]

"Steinar H. Gunderson" <se...@debian.org> wrote:
> It sounds pretty harsh to break a feature used by even the default configuration.

Iʼm afraid, that Iʼve failed to locate where switches `-n` or `-e` (and command line options at all) are used in the default setup.

> I do agree it is problematic not to support pruning filenames with spaces in them, though; how would you feel about escaping them in the configuration file

Well, Iʼm glad, that youʼve asked, as that allows me to highlight a quite minor, yet another UI/UX problem: since configuration file cannot be neither overridden (`--config FILE`) nor disabled entirely (`--no-config`), I actually feel about it like about a missing stair I have to bear in mind. It other words, it would not be much of an issue if updatedb did not support config files at all, and all necessary options were specified in a wrapper script or even directly in systemd-unit / initscript.

Even if there is a need for a file (for instance, there are concerns about exceeding the length limit), I believe that inventing (and supporting) a separate format for it does not really worth it. Treating its content as an initial part of command line (with an optional exception of allowing comment lines) simplifies things a lot at least for a user (and I hope for developer too). Thatʼs an approach, that, say, youtube-dl(1) takes.

> and then a flag like --add-single-prunepath that does no splitting?

If thatʼs a question, whether long options that do no splitting have to be named differently, then yes, sure, as they are explicitly plural now. And presumably just `--add-prunepath` differs enough to be used.

[Steinar H. Gunderson]

On Fri, Nov 12, 2021 at 04:41:48AM +0300, Dmitry Alexandrov wrote:
>> It sounds pretty harsh to break a feature used by even the default configuration.
> Iʼm afraid, that Iʼve failed to locate where switches `-n` or `-e` (and
> command line options at all) are used in the default setup.

But /etc/updatedb.conf is read by default, uses the same space-separated
syntax, and has spaces in its argument in the default configuration.

> Well, Iʼm glad, that youʼve asked, as that allows me to highlight a quite
> minor, yet another UI/UX problem: since configuration file cannot be
> neither overridden (`--config FILE`) nor disabled entirely (`--no-config`),
> I actually feel about it like about a missing stair I have to bear in mind.
> It other words, it would not be much of an issue if updatedb did not
> support config files at all, and all necessary options were specified in a
> wrapper script or even directly in systemd-unit / initscript.

OK. I am afraid your feelings about how much of an issue it would be are
probably not universal, though.

>> and then a flag like --add-single-prunepath that does no splitting?
> If thatʼs a question, whether long options that do no splitting have to be
> named differently, then yes, sure, as they are explicitly plural now.

Well, it's not like I would design a system with this splitting if I made one
from scratch, but you know, if you go around changing even the smallest of
things between mlocate and plocate, there will be angry bug reports
complaining of changed behavior. :-)