piu icon indicating copy to clipboard operation
piu copied to clipboard

Refactor Arch Linux's `piu files`

Open beyondmeh opened this issue 4 years ago • 4 comments

# HELPWANTED:
# The below code will fail on similar named packages
# like chromium and chromium-bsu. The problem is two-fold
#
# 1. pacman searching needs to use ^PACKAGE$ to match 
# exact names. `pacman -Qs $$@^` doesn't work, but how to 
# properly escape is beyond me.
#
# 2. Output from `pacman -Sw` should be captured to get the
# exact filename of the package. Calling `ls` is sloppy 

if ! pacman -Qs "$@" >/dev/null; then
	sudo pacman -Sw --noconfirm "$@"
	pacman -Qlp $(ls /var/cache/pacman/pkg/$@*)
else
	pacman -Ql "$@"
fi

beyondmeh avatar Dec 03 '20 19:12 beyondmeh

I could probably help with this since i'm running manjaro casually. Can you give an example of how a successful scenario should look like? Like, what is the command ran by piu and what should it find vs what it does now

gtsop avatar Dec 17 '20 19:12 gtsop

Line: pacman -Qs "$@" >/dev/null; then

Essentially piu calls pacman in a way that performs a lazy search on packages when it should perform an exact match only. This could potentially fail on similarly named packages. pacman has this feature built-in: pacman -Qs ^PackageToInstall$. The ^$ denote the package starts with "exactly the following".

Now consider the package we're searching for with piu is in a variable, $@. So to search for the exact package we need call pacman -Qs ^$@$, combining our package variable $@ and pacman's ^$ logic. This doesn't work.

  • We could expand the variable, then add in ^$ before passing it to pacman. One way would be to create a new variable in bash that combines everything
  • We could simply ignore ^$ and call pacman as-is then grep the results
  • We could escape $@ in the pacman command, but I have no idea what that would look like

Line: pacman -Qlp $(ls /var/cache/pacman/pkg/$@*)

This line is pulling the exact name of the downloaded package. Packages on disk have a version string after the name and a file extension like txz. Calling ls to get the full name of the package is sloppy and could be prone to errors if there's multiple versions of the package installed or similar named packages.

The previous line sudo pacman -Sw --noconfirm "$@" outputs most of the package's name with it's version, which we could capture and then use to find the package on disk.


So to summarize, piu currently works as-is, but the solutions are prone to issues down the road. The example chromium and chromium-bsu is somewhat deceiving as piu handles these correctly. However, you can see that Arch has packages that share similar names, and it is entirely possible piu would fail on one of these, unless it does exact matching

beyondmeh avatar Dec 20 '20 21:12 beyondmeh

Now consider the package we're searching for with piu is in a variable, $@. So to search for the exact package we need call pacman -Qs ^$@$, combining our package variable $@ and pacman's ^$ logic. This doesn't work.

Ah! I see. That's a quick one, all we need is an escape char right there like so pacman -Qs "^$@\$". Will make a PR for that

gtsop avatar Dec 21 '20 02:12 gtsop

@beyondmeh Having a second look at this, do you think pacman -Ql $@ can do the whole work?

From the hlep page (pacman -Q --help):

-l, --list  list the files owned by the queried package

Running it seems to work just fine. Wanna give it a try yourself?

gtsop avatar Dec 21 '20 02:12 gtsop