How can I access the information Yay provides

According to [SOLVED] Does yay and paru keep a log? / AUR Issues, Discussion & PKGBUILD Requests / Arch Linux Forums Yay processes are logged via pacman, the man says “Yay is a Pacman wrapper with AUR support. It passes options to Makepkg and Pacman after resolving packages to install/upgrade.”

But when Yay is running, it whizzes hundreds of lines of code past, including more than one ‘Warning…’, yet none of these seem to appear in either pacman logs nor any makepkg logs (at least not that I can find).

So where would I look to find what those warnings were all about, they zoom by so quickly we can’t possibly be expected to read them, not to mention the paranoid part of me wanting to just have a record of all that activity (installing an AUR package really does seem to download half the internet before it can compile!)

I’m aware that this has sort of been asked before at How to read yay update log?, but the thread meandered off into finding dependencies so never actually ended up with anyone talking about where all that script went…

Hi @IBraham,

Warnings are usually just that: a warning, a notice that there is the possibility of something amiss. Usually you don’t need to worry. An error on the other hand, might need more information, stat,

If you want to inspect what happened at a more leisurely pace, you can use:

tac /var/log/pacman.log | less

If you want to look at all warnings in the log:

grep --ignore-case warning /var/log/pacman.log | sort --reverse | less

If you want to check for all errors in the log:

grep --ignore-case error /var/log/pacman.log | sort --reverse | less

Hope this helps!

man yay
says, in the section on FILES (almost at the end)


but I think what you are after is not kept

With makepkg you should have access to all the logs that are created during compilation - in or below the same directory you called it from.

You could also adjust the scrollback buffer of your terminal if there are too many lines and not all of it can be seen when scrolling back.

Or look up how to redirect terminal output to a file - I don’t know off the top of my head how to do this and thus can’t give an example.

1 Like

You should be able to redirect the output to a file:

yay -S something > /path/to/file

# or append to an existing file
yay -S something >> /path/to/file

# or perhaps better yet, output to file and stdout (terminal)
yay -S something | tee /path/to/file

# or append to an existing file
yay -S something | tee -a /path/to/file

I suggest you ask yay to use a logfile

 $ yay --help
--logfile <path> set an alternate log file

good call
strange that this info is not in the manual - it doesn’t mention a log file

1 Like

That’s reassuring, thanks.

Cool. I’ve had a look at the pacman logs after installing an aur package, and it gives me a few lines (basically saying everything went OK), so I assume your first comment was the case here - nothing to worry about.

1 Like

Thanks, but I don’t see an option to return to default in the help. If I don’t know where the log-file currently is, I’m concerned about not being able to ever reset it to it’s normal place… Am I missing something?

The --logfile option only changes it for the current command. Just leave the option out and it’ll use the normal logfile.

Unfortunately it’s not what you’re looking for, as the normal log is /var/log/pacman.log

Example output:

# /tmp/yay.log
[2024-04-10T14:26:25+0100] [PACMAN] Running 'pacman --logfile /tmp/yay.log -U --config /etc/pacman.conf -- /home/dmt/.cache/yay/paru/paru-2.0.3-1-x86_64.pkg.tar.zst'
[2024-04-10T14:27:45+0100] [ALPM] running '00-timeshift-autosnap.hook'...
[2024-04-10T14:27:45+0100] [ALPM-SCRIPTLET] ==> skipping timeshift-autosnap due skipRsyncAutosnap in /etc/timeshift-autosnap.conf set to TRUE.
[2024-04-10T14:27:45+0100] [ALPM] transaction started
[2024-04-10T14:27:45+0100] [ALPM] upgraded paru (2.0.1-1 -> 2.0.3-1)
[2024-04-10T14:27:45+0100] [ALPM] transaction completed
[2024-04-10T14:27:45+0100] [ALPM] running '30-systemd-update.hook'...
[2024-04-10T14:27:45+0100] [PACMAN] Running 'pacman --logfile /tmp/yay.log -D -q --asexplicit --config /etc/pacman.conf -- paru'
1 Like

I suspected that much :grin:

EDIT - I was thinking piping the output - just as @dmt did - I had to refresh my memory by testing

yay -Syu | tee ~/yay-log.txt

How about a little script:


# DESC: Install an AUR package using yay and redirect 
#       output to a log file. Takes a single package name.

logdir="~/.cache/yay/logs"         # change if you want

mkdir -p "$logdir"                 # ok if exists
yay -S $1 | tee "$logdir"/$1.log   # outputs to terminal and logfile

Save the script to ~/.local/bin as yayt (or yay-install, whatever), and make it executable:

chmod +x ~/.local/bin/yayt   # or whatever you called it

Then use it like this:

yayt packagename

Oh well. I suppose it can’t log everything. Seems weird to think it’s flashing all these messages up on screen for no-one to ever read… Who is it talking to…?

Cool. Thanks.

1 Like

It’s for you to read (or not).

Mmm. Back to the beginning then. If it’s for me to read, why isn’t is saved somewhere or paused by a prompt at the end of each page saying ‘Have you read this yes (Y/n)?’

Seems odd to have a load of text for me to read but then pay no attention to whether it’s presented in a format (or at a speed) that is actually readable. We’re not all spring chickens…

With that comment we are diverging - and that discussion is irrelevant to how yay and paru works.

If you want to discuss the functionality of yay or paru - you should use the upstream repos.

You can find that info using CLI or you can use Add/Remove Software from the app launcher menu

 $ pamac info yay | grep -e 'URL'
URL                   :

 $ pamac info paru | grep -e 'URL'
URL                   :

It’s rather easy - use makepkg and you compile one package at a time.

Then you have easy access to the build logs - and, as was already said
you can simply scroll back up to read …

If you use a helper tool like yay - it becomes a bit more complex to preserve the output
of it building multiple packages at once.

You can still scroll back though.

It is designed to do the job - not to preserve console output.

I just tried the script that @dmt suggested - but got no output from it.

Here is my take.
It captures all kinds of color codes and the output is ugly - but it also captures the relevant information.

script -B ~/logfile -c "yay -S package_to_build"

then read the ~/logfile

The actual example I tried this with was this:
script -B ~/logfile -c "yay -S canon-pixma-ip7200-printer"
(it fetches a few dependencies and then builds the package)
remove with:
sudo pacman -Rns canon-pixma-ip7200-printer
because it was just an example …

You usually only want to read the output if there are errors and the process failed because of it.
Then the error message usually is near the last lines of output and you can, again, simply scroll back up to read.

Or copy/paste - put it into a file … your choice

1 Like

That’s what happens when you don’t test it. :man_facepalming:

The quotes were messing things up…but we still miss a lot of the output.


# DESC: Install an AUR package using yay and redirect 
#       output to a log file. Takes a single package name.

logdir=~/.cache/yay/logs         # change if you want

mkdir -p $logdir                 # ok if exists
yay -S $1 | tee $logdir/$1.log   # outputs to terminal and logfile

Very nice. I didn’t know about script, thanks. :smiley:

Looks good if you use less or cat (colour codes work), but the colour codes can be stripped out using a regex.

sed -r  $'s/\033\[[0-9;:,]*?m//g' ~/logfile

thanks for this:

cat ~/logfile displays it flawlessly, but … no pager

same as your sed expression

less -R ~/logfile
looks almost clean
it looks identical (to me) as when I pipe your sed expression through less, to have a pager

so this:
script -B ~/logfile -c "yay -S package_to_build"
less -R ~/logfile
would definitely be good enough for me
if I was actually interested in it like the OP seems to be :face_with_peeking_eye:

1 Like

less -R ~/logfile and less ~/logfile produce identical output for me, both have working colour codes and still have some annoying chars eg. ^O.

The sed command will strip colour codes out and leave the rest, so it looks better in a text editor. Unlike less and less -R on their own, there isn’t any colour, but otherwise yes it looks identical.

I just noticed script saves your password in clear text.


less ~/logfile would do for me too, I like colour. :smile:

Yes - the purpose and intention of using script is … to make a typescript of the session.
Everything is captured … do not share frivolously.

I didn’t even try that - it didn’t cross my mind to do:

sed -r s/\033[[0-9;:,]*?m//g’ ~/logfile > ~/logfile1

and then read ~/logfile1 in an editor.

I guess we rather successfully solved a problem which neither of us actually had. :grin:
It was fun. Thanks for playing along.

1 Like