A flag to treat the arguments as OR like mlocate did instead of the default to AND would be great, though I wish plocate would have more closely mimicked mlocate's default behavior from the beginning and had a flag for AND instead. Unfortunately, one cannot go back in time.
On Thu, May 23, 2024, 20:04 Dominique Martinet <asmadeus@xxxxxxxxxxxxx> wrote:
Christopher wrote on Thu, May 23, 2024 at 06:26:57PM -0400:
> One thing I've noticed is that plocate behaves differently when
> supplied with multiple arguments than mlocate. This broke some of my
> scripts.
>
> Previously, I had:
>
> locate rpm{old,new,save,orig,moved}
> # expands to locate rpmold rpmnew rpmsave rpmorig rpmmoved
>
> But now, I need to do:
>
> for x in rpm{old,new,save,orig,moved}; do locate "$x"; done
>
> The frustrating part is that it didn't even break in an obvious way.
> It just ignored all the arguments after the first one, so it was only
> searching for rpmold, and ignored all the others.
>
> In this way (and perhaps only this way?), mlocate was better. plocate
> should handle these arguments, or at least fail with a message letting
> you know that it is ignoring the rest of the arguments.
Looking at the code[1], it's supported multiple arguments since 1.0.0
(2020) so basically forever as far as fedora is concerned; but while
mlocate was looking for each argument individually (according to your
report) plocate is adding, plocate is looking for files that match all
the arguments given; so it's a pretty extreme change of behaviour...
At this point changing it will break scripts for people used to the new
plocate behaviour, so I'm not sure there's a good solution here - perhaps
a new switch that'll toggle whether we want matches for all the words
(plocate behaviour) or all matches for each words (mlocate behaviour)?
Either way, it's something to report upstream so I've added Steinar in Ccs.
[1] https://git.sesse.net/?p=plocate
--
Dominique Martinet | Asmadeus
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
