PacUI: Bash script providing advanced Pacman and Yay/Pikaur/Aurman/Pakku/Trizen/Pacaur functionality in a simple UI

cli
pacui
aur
pacman
yay

#341

yes.

the reason is the second function called “func_diff” which is not listed in the UI, because it is a helper function (the only one besides “function pacui_clean” in pacui).

the fifth function is called “func_r”. the “r” stands for “Remove Packages + Deps” (which can be called directly in the terminal with “pacui r”).


#342

Getting there, trying to understand what it does, but 0200 here - time for bed.


#343

Hope you do not mind some questions :smiley:

In func_r what does $input2 do and where does it get its value? Can’t work it out…

0300 really must go to bed :zzz:


#344

thanks for reporting about your new-reader-of-pacui-code experience.
i have just added many comments and a bugfix. please reinstall pacui-git to get the latest changes.

$input2 is an important variable in pacui. it gets used all over the place. this is probably the reason you cannot find its definition when searching for it in your code editor (or github) with CTRL+F.
$input2 only contains value(s) when pacui is start from the terminal. it contains the second (and all further) arguments specified in the “pacui” command.

here some examples:

"pacui r firefox" --> $input2 contains "firefox"
"pacui i web browser" --> $input2 contains "web browser"
"pacui h" --> $input2 contains "" (nothing)
"pacui h this isREALLYjunk" contains "this isREALLYjunk". but the "help" option ignores the content of $input2.

here the definition of $input and $input2:

i agree that the code section i have just linked is kind of important for the overall understanding of the code. but unfortunately, it has to be placed there.

  • do you think a table of contents for the code would improve the situation?

  • would splitting the code into different files improve the situation?
    (i want to prevent this, because it is really handy to download a single file from github, mark it as executable, and run it)


#345

I use PacUI as my daily horse for system maintenance and I really love it.
At the same time I wonder how Manjaro can solve the gap to become really user friendly, if I think about pacnew configurations and the manual way of running pacdiff.

Is there any way to handle this auto-magically for inexperienced users, which could be implemented into pacui or pamac?


#346

yes of course. it would involve a lot more work for maintainers and a lot less freedom for users, but it is possible.

.pacnew files (and how you merge/use them) is tricky. if you want to make this process user-friendly, you simply lock down all config/settings files (by distributing them in packages), which only maintainers can change. then, they can decide whether to use a .pacnew file or use the old configuration files (by looking up, whether the configuration syntax of a package has changed or not). this means the user could only make temporary changes in config/settings files. also, there are no maintainers in the manjaro team to do all this work.
the best place to do something like this would be arch linux package maintainers. they are maintaining the packages anyway. they could maintain the config/settings files, too.

currently, manjaro simply ignores .pacnew files. this works well until the syntax of config/settings files changes. then, the package breaks (partially) and might even stop working completely.

overall, i think this is a consequence of arch linux: arch linux is not meant to be a user-friendly system, but an easy and simplistic system (from the developers point of view).
if you want to change that, you need at least the same number of developers/maintainers as arch linux - and manjaro has nowhere near that many volunteers.


#347

1>. No.

2>. No.

Just better comments.

But thank you, learned a lot about fzf in practice :smiley: I use it but probably only 10% of its power.


#348

when you can think of improvements (new functionality, better/other code comments, simplifications of code or functionality, etc.) feel free to suggest it in this thread.

i am always happy, when pacui gets improved.

i tried to give a short introduction to pacui on its main github page (and the first post in this topic). pacui offers a lot to power users, who already know what pacui’s options are good for. pacui can be called from the terminal directly. the first command to learn is “pacui h”, which gives you a short overview of all available commands.


#349

TBH I am happy on the command line, but will give it a go.


#350

i have noticed another problem in pacui: when i use pacui in tty (not in a desktop environment terminal), there are visual problems. it looks like lists displayed using fzf do not properly clear the screen before the display a list of packages. when fzf quits, the screen is not cleared, too.
pacui still works, but it is really hard (especially for people not knowing pacui’s options by heart) to see what they have to do.
as a workaround, i tried to manually use the bugfix mentioned in this old post in order to clear the screen before fzf starts and after it quits. unfortunately, this did NOT work. i have tested the “clear” command and it works.

this means we have a dilemma here. we have to choose one of the following possibilities:

  • either pacui looks good (and is usable) in tty
  • or pacui uses the terminal history. you can scroll up and see all previous pacui commands (including their output) and the rest of your terminal history

personally, i think it is more important to fix pacui in tty. what do you (and other people) think?


#351

I would like to mention that the problem in tty does not occur if pacui runs in tmux. A fix is probably still needed, but maybe this can be taken into account in the fix? In this way terminal history would still be available when used with tmux. Maybe trigger the fix only if

 !  [[ "$TERM"  == "linux"  ]]

#352

thanks for your suggestion.

i did some tests and found out that “$TERM” is identical on my machine both in tty and terminal.
but the “tty” command is different in tty and non-tty environments.

p.s.: i did some tests in zsh and bash, terminal and tty and adjusted my code. i just did a push to github. “pacui-git” can be built with the latest changes and should preserve history in terminal (and most likely tmux) and fix the visual glitch in tty.
please report back, if something is still broken.


#353

because of a recent bug report, i am thinking about removing support of yaourt from pacui completely unless there is somebody, who really wants it.

please tell me what you like:

  • I am fine with complete removal of Yaourt support from PacUI.
  • I want to use PacUI exclusively with Yaourt instead of Pacaur.

0 voters

(simply making pacaur a dependency of pacui does not make sense, because pacaur is used by default it is found the user’s system)
(personally, i am strongly against making yaourt a dependency of pacui)


#354

i have just overhauled pacui in order to make its UI even simpler.

in this process i have:

  • removed “empty package cache” option
  • moved “force install packages” option to “install packages” option (but only make it available when this option fails)
  • moved “force remove packages” option to “remove packages” option (but only make it available when this option fails)
  • moved “force update system” option to “update system” option (but only make it available when this option fails)

i did all tests i could think of, but i did not find a way to test all possible cases.

all changes are available in the latest pacui-git version. please report bugs, if you find any.


#355

Will it become functional at least for installing from Manjaro repos if you remove yaourt support?
Because without yaourt or pacaur installed I cannot install anything not even from Manjaro repos with pacui 1.8-1.


#356

when i remove yaourt support, pacaur will become a hard dependency of pacui (see below for pros and cons).
currently, pacman-mirrors, reflector, pacaur, and yaourt are OPTIONAL dependencies, but you need (some of) them for pacui.

here is the problem:

  • when i make yaourt a hard dependency, pacui will always work. you could simply install pacaur when you want to use it instad. personally, i do not like to have yaourt installed when i want to use pacaur instead (and do not need yaourt otherwise). because yaourt has a bad reputation, people are probably annoyed when i make it a hard dependency.
    also, i am not using yaourt any longer. i do not want to make it a hard dependency (and therefore first choice) when i never actually test it. pacui could stop working with yaourt completely without me noticing.

  • when i make pacaur a hard dependency, pacui will always work (except on arch linux when people are not clever enough to install cower (=a dependency of pacaur)). also, pacui will always use pacaur when it is detected. this means that it becomes impossible to use pacui with yaourt only. in this case, i can simply remove yaourt support altogether.

  • pacui will not work (properly) when pacman-mirrors is not installed. but i cannot make pacman-mirrors a hard dependency, because pacman-mirrors is not available on arch linux.

i know.
when nobody really wants yaourt support and tells me within the next couple of weeks (or maybe a month), i will drop yaourt support.

p.s.: what do you think about a warning when neither yaourt nor pacaur is found on the users system?


#357

I do not understand, now that pacaur is abandoned you should rather remove the pacaur support but no yaourt ?


#358

oh wow - pacaur is indeed unmaintained.
thanks for telling me! i have completely overlooked these news.

it looks like pacaur will keep working until pacman 5.1 is released. in the meantime, i have to look for another aur helper.

p.s.: i am currently looking at aurutils, trizen, and yay.


#359

#360

It works on archlinux32, but haven’t got the case that I needed to “force” sth.