Updates (reverse chronological order)
Do let me know if you find any bugs. This script is pretty much going into a maintenance stage since I can't think of any more features to add. Adding --jobs was the most difficult for me, but now that is done, and the script is stable. I would like to keep it stable which implies I should leave it as it is.

Brief Description:
I am providing this script on a request at the monthly screenshot thread. What this script does is provide a nice timer, while emerging packages. An example screenshot is present in http://oi51.tinypic.com/1ze820g.jpg

How it works:
The script first checks if the emerge process will proceed properly, by doing a emerge --pretend. If the emerge process was successful, then the script launches emerge via

Code:

emerge <rest of the command line options> 2>&1 > output_file &

Since --quiet-build is now the default in emerge, this script now doesn't launch emerge as emerge -q.
The program then repeatedly checks the output of emerge in output_file for updates and accordingly provides an updated terminal output.

Usage:
The script should be run simply as if you were running emerge. To facilitate a nice output as shown in the screenshot, it is recommended to not use emerge options such as -c, -C, --sync. The script itself takes no arguments other than -h or --help and passes all the rest of the arguments to emerge.

If the script detects any unsupported arguments, then it simply executes emerge directly, bypassing all the other setup in the script.

This is a bash script and its compatibility with other shells is unknown. It will definitely produce tons of errors if called as some other shell. So you can either make the script executable (chmod 755 quietemerge) and then just run it as quietemerge, or run it as bash quietemerge.

In order to temporarily override the settings present in the config file, prepend the variable with an underscore _ and provide it as an environment variable.
An example where I want to override the config file setting temporarily, and/or provide a temporary setting:

Installation:
Copy the script to some directory which is in $PATH of root. Personally, I have it installed in /usr/local/sbin.

Dependencies:
Till version 20100407: The script depends on app-portage/genlop.
From version 20110422: No dependency on genlop.

Configuration:
The script creates a configuration file $HOME/.config/quietemerge.config. It is not mandatory to modify that file,- I have tried to keep the defaults sane. However, if you want to mount tmpfs on to /var/tmp/portage or run your favourite config update utility after emerge is over, I would suggest looking at the configuration file.

zsh completion configuration:
If you use zsh, then you can perform the following steps to enable command line autocompletion of quietemerge in zsh.
New instructions for zsh completion:

Thanks for all the work you've put into posting this . I'm going to test it tonight.

Used it for a few merges now and I'm very happy with it, no bugs yet . Altough there are a few 'features' i would love to see: see how many merges are going to happen. Also, it's in my opinion very scary to do 'the shot in the dark' emerge -uDN world, would it be possible to make it display first what packages with the --ask? .

Thanks for all the work you've put into posting this . I'm going to test it tonight.

Used it for a few merges now and I'm very happy with it, no bugs yet . Altough there are a few 'features' i would love to see: see how many merges are going to happen. Also, it's in my opinion very scary to do 'the shot in the dark' emerge -uDN world, would it be possible to make it display first what packages with the --ask? .

Interesting. I will give it some thought on how to introduce these features. Give me a couple of days. I will try to script it in the weekend.

My main objective is to have no arguments for the script itself (except -h). All the arguments should be exactly the same as you give to emerge.

EDIT: By the way, you do get the total number of merges, the current merge number and the total time left. Look at your terminal titlebar _________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

Since this [great] tool relies on genlop, you might be interested to take a look at this bug. I've submitted a patch so that "genlop -p" is faster at estimating the time emerging a large set of packages should take.

Since this [great] tool relies on genlop, you might be interested to take a look at this bug. I've submitted a patch so that "genlop -p" is faster at estimating the time emerging a large set of packages should take.

Cheers!

Very nice
I know that genlop -p takes significant time. That is why I don't call genlop -p everytime,- it is run only when a new package is being emerged and then it updates the terminal's window titlebar with the total estimated time left. What runs in a loop is genlop -c.

I hope your patch gets accepted. That way everyone will benefit

This is one reason why I run emerge in the background. So, the emerge process runs independently of the time estimating process (genlop). After all, we also care about how quickly the emerge process finishes instead of just some pretty output. I am sure no one would want pretty output if it delayed emerge.

PS: I completed writing the code to take care of --ask last weekend, but I didn't get the opportunity/time to test it completely. I will test it by this weekend and release it after that._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

PS: I completed writing the code to take care of --ask last weekend, but I didn't get the opportunity/time to test it completely. I will test it by this weekend and release it after that.

Will we see the actual estimated time before we can say "yes"?

I hadn't thought of that! Good idea. I will include this too (It should be quite easy to provide this estimate). However, I think I will provide only the total time and not time for each package since the latter will be a complete beast._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

That is strange. I have no idea what that was
I am using emerge and taking all stderr and stdout to /tmp/output.log. Can you check /tmp/output.log (if you still have it around) and check what is printing before the coreutils package? My script does not give any such output.

It looks like some output from emerge perhaps overwrote the "Emerging <package>" region, just enough to keep the "Time left:" part alone. This must have happened with the coreutils package. Since emerge will spit out a newline and not erase the rest of the line (the "Time left:" part), my script will start printing from the next line. This makes it pretty certain that it is in the emerge of the coreutils package that that line is being printed. It also gives the time .. you had 1min and 15sec of coreutils emerge left. So, you can even run a normal emerge and see whether emerge spits out that line when around 1min and 15sec is left Some command like this should suffice:

Code:

emerge -q coreutils 2>&1 > tmp.out

EDIT: I just tried it myself and I didn't get that output. So, it is specific to your system.
EDIT 2: Fix the emerge command redirection above. Saw the mistake after many hours _________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

EDIT: Finally realised what I was doing wrong. I used emerge 2>&1 > output_file instead of emerge > output_file 2>&1. The order matters Anyway, I am using the bashism emerge >& output_file in the latest version of the script. So it should be fine. _________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

Version 20091030. Changelog:
Just one bug fix: Remove the skipped package from tmp file so that the correct count and correct remaining time is given by genlop._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

Great script! I'm not sure if EWARN/ELOG and configuration file update messages are being handled nicely though? It looks to me as though a line has been dropped and the order rearranged a bit in the output below:

WARN: install
If you are upgrading from Dovecot 1.1, read
http://wiki.dovecot.org/Upgrading/1.2

EDIT: Ah, I notice that /tmp/output.log contains the proper EWARN and ELOG messages.

EDIT2: Well, I wasn't using the latest version, I was using the 29th Oct version. I upgraded to the most recent version and emerged just syslog-ng to check what happens and it printed correctly, so either you fixed it in the update, or there were conflicts with having several messages to print in my earlier update.

* It is highly recommended that app-admin/logrotate be emerged to
* manage the log files. syslog-ng installs a file in /etc/logrotate.d
* for logrotate to use.
* GNU info directory index is up-to-date.

Great script! I'm not sure if EWARN/ELOG and configuration file update messages are being handled nicely though? It looks to me as though a line has been dropped and the order rearranged a bit in the output below:

The fact is that I don't handle ewarn/elog at all! That is because emerge -q or emerge -qv does not output any ewarn or elog, as far as I could see. If it does output any ewarn/elogs, I think it outputs only a small subset. The output you are seeing (as you wrote under EDIT2) is actually simply the last 10 lines of /tmp/output.log. I output that just to let the user know that configuration updates are pending

ewarn/elogs are better read by a different program such as elogv or elogviewer.

About rearranging the order, it seems you were probably using the version from 26th Oct or earlier. This had the bug that jprobichaud mentions a few posts earlier. The bug was that stderr was not being redirected to the /tmp/output.log. The reason was that I had mistakenly put the 2>&1 before the output redirection (see just two posts earlier). This bug was fixed in the release of 29th Oct. The bug fix in the 30th Oct release is very different and really minor,- the terminal title would not have been updated correctly. One would have hit that bug only if one used --keep-going and if some package failed to merge.

The fact is that I don't handle ewarn/elog at all! That is because emerge -q or emerge -qv does not output any ewarn or elog, as far as I could see. If it does output any ewarn/elogs, I think it outputs only a small subset. The output you are seeing (as you wrote under EDIT2) is actually simply the last 10 lines of /tmp/output.log. I output that just to let the user know that configuration updates are pending

Ah, cool. No bugs, but a feature request: Would it be possible/simple to print the time taken to emerge each package where you're currently printing 'Done!'?

The fact is that I don't handle ewarn/elog at all! That is because emerge -q or emerge -qv does not output any ewarn or elog, as far as I could see. If it does output any ewarn/elogs, I think it outputs only a small subset. The output you are seeing (as you wrote under EDIT2) is actually simply the last 10 lines of /tmp/output.log. I output that just to let the user know that configuration updates are pending

Ah, cool. No bugs, but a feature request: Would it be possible/simple to print the time taken to emerge each package where you're currently printing 'Done!'?

It should be possible and simple to do this. I will give it a try._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

Ah, cool. No bugs, but a feature request: Would it be possible/simple to print the time taken to emerge each package where you're currently printing 'Done!'?

This is now available in version 20091102

Changelog:

Determine the PORTAGE_TMPDIR by portageq, and mount tmpfs on to PORTAGE_TMPDIR/portage (for people who do not compile in /var/tmp/portage)

Added a new config option: SHOW_MERGE_TIME. If it is 1, then time spent on the merge will be shown instead of "Done!". To set it to 1, do a

Code:

echo "SHOW_MERGE_TIME=1" >> ~/.config/quietemerge.config

Adding it was simple but I realised that the script was getting complex and repetitive in many places. I wanted to put some of the repetitive parts in a function. But it seems it will take a bit of time and may introduce unwanted bugs if not done properly, and I want the script to remain bug free. So, cleaning up the script is postponed for later._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

~> genlop -t "=dev-libs/apr-1.3.9" --date 2 minute ago
Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1039, <_GEN_0> line 23512.
Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1040, <_GEN_0> line 23512.
Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1042, <_GEN_0> line 23512.
* dev-libs/apr