Yes, I know. But I want to update pacman packages first before any AUR packages are touched. Because AUR packages are more prune to update errors, at least pacman packages will be updated guarrantee this way. There have been cases when YAY could not update packages, but PACMAN could. So I don’t care if both commands will check pacman.db twice for the sake of it.
That should always be the case if you update via yay, AFAIK. But there is nothing wrong with using a log file. I don’t think you can make that any better if you want the output to be displayed properly.
I would argue that it’s overkill for such a simple task. You want the information and you get it this way without any hassle. You could even omit deleting the log file, because it gets deleted anyway inside the /tmp folder.
You could do it in a variety of ways. If /tmp is mounted on a tmpfs, I am not sure they would actually add any value though. A tmpfs is already in memory.
Well, the main difference between file output and collective stream output would be that I would not use wait command anymore. And would output already collected stream data to screen and the rest that comes after, in a live manner.
File output method I’m currently using, need to wait for flatpak to finish fully and only then outputs snapshot of what has happenned in all that time. No live outputing of flatpak after yay finishes.
Does named pipe stores writer’s data in memory until reader connect, or does named pipe simply halts the writer process until reader process will pick up the writer’s content?
Yea so to allow for pipe writer to not freeze and do process asynchronously, I used mbuffer - measuring buffer . Probably should choose some other more specialized buffer program, but I don’t know/care about mini efficiency too much; I just wanted to make update process faster by parallelizing it and without gibberish result output.
Perhaps something to add here. After sudo pacman -Syu you can run yay -Sua. Doing this tells yay to only update AUR packages and ignore the main repos.