UNIX snapshot update 'one liners' and scripts
Friday, October 2, 2009 7:17:00 AM
Originally posted by ruario:
The debian packages are by far our most popular Linux download so they got a repository first. Additionally there is more that one rpm update system (apt-rpm, Urpmi, Zypper, Smart Package Manager, etc.), and if you start considering non .rpm distros as well the multitude of update systems on Linux/UNIX gets ever larger (slackpkg, slapt-get, Swaret, pacman/Yaourt, Portage, etc.). As you can imagine the decision about what to support is therefore quite hard. Additionally, a number of distros (Gentoo, Arch, SUSE, Linux Mint, etc.) include us in their own official or community repositories anyway meaning that further repositories are often unnecessary. All that said, we are of course constantly reviewing this situation and we may add an rpm based repository in the future.
Also, it is worth mentioning that snapshots are not currently available on the debian repository anyway, so the users of debian based systems are also downloading these snapshots 'manually'. For more information on this read the "Why no snapshot auto-updates?" section of my recent blog post.
If you feel it is too 'manual', it would be fairly simple to knock up a shell script utilising wget (or curl) to auto grab your favoured package and install it (I'm not recommending you do so but it could be done), e.g. a script that does something like:
1. Pull the rss feed.
2. Extract the first blog post link and grab that page.
3. Extract the 'snapshot.opera.com/unix/....' link.
4. Parse the sub-directory and build number to work out the download link to your favoured package.
5. Grab the package and pass this to your package manager for install (or extract and install with the tar package).
This got me thinking about exactly how easy this would be to do and it occurred to me that I could probably do it with a one liner (albeit a fairly long and ugly one liner). Here is what I came up with after a just a couple of minutes thinking.
Edit: I recently wrote something a little longer that will detect your architecture and download the latest 10.6x+ snapshot build, unpack it and set and title pref so that you can keep track of which build is which:
http://people.opera.com/ruario/examples/testing/getsnap
Before I go any further let me state that these examples have no error checking. They are meant as very quick demonstrations, to show what can be done with relatively little effort. On the other hand, despite the lack of error checking they are all quite usable. Most possible failures would give the same net result: failure to download.
Note: Since I am not error checking in these examples I have not provided any example that passes the file straight to the package manager for install, as I'm slightly concerned that a novice user might take such an example and run it without concerning themselves with the potential problems they may encounter if things did go wrong. However it is trivial to actually implement this even as a one liner (if you so desired), as many package managers can handle a URL as an input string.
The following example is the simplest and demonstrates automatic download of the most recent Linux G3 i386 .rpm package, but you could easily alter this to whatever is appropriate for your system:
wget -nv http://my.opera.com/desktopteam/blog/ -O - | grep snapshot.opera.com\/unix | head -1 | sed -e "s/.*\(http.*\)\" target.*/\1/" | wget -i - -r -erobots=off -nd -np -A gcc4.shared.qt3.i386.rpm
For this first example (only) here is a brief explanation of how the various parts work:
1. Get the HTML contents of the Opera Desktop Team Blog.
wget -nv http://my.opera.com/desktopteam/blog/ -O - |\
2. Find all references to snapshot.opera.com/unix in the raw HTML (these are links to the UNIX snapshot download pages), ignoring everything else.
grep snapshot.opera.com\/unix |\
3. Delete all but the first (most recent) link.
head -1 |\
4. Remove all the extraneous HTML leaving only the actual link itself.
sed -e "s/.*\(http.*\)\" target.*/\1/" |\
5. Using this link, search through the available sub directories for a package that ends 'gcc4.shared.qt3.i386.rpm' and download it, saving nothing else.
wget -i - -r -erobots=off -nd -np -A gcc4.shared.qt3.i386.rpm
Here is another way, this time using curl instead to download the latest equivalent .deb package:
curl -s http://my.opera.com/desktopteam/blog/ | grep snapshot.opera.com\/unix | head -1 | sed -e "s/.*\(http.*\)\" target.*/--url \1intel-linux\//" | curl -s -K - | grep -e title.*intel-linux -e gcc4.*qt3.i386.deb | tr -d '\n' | sed -e "s/.*\(.unix.*linux\).*a href=\"\(opera.*deb\)\".*/--url http:\/\/snapshot.opera.com\1\/\2/" | curl -# -K - -O
That looks a fair bit more complex, purely because curl (for all its power) does not have native recursion. On the plus side it would be slightly faster, as it is not recursively checking all subdirectories to locate the correct package.
One advantage of these examples being done on single line is that they don't even need to be saved as scripts, a shell alias is enough, i.e. you could alias 'osnap' (Opera snapshot) for the entire command.
A even neater trick with the tar packages, is extracting their contents on the fly. After download you can simply 'cd' into the created directory and run Opera in place via './opera &', which would mean that the main opera installation (both the install and preferences) wouldn't be touched. Great for trying the snapshots, with the least risk of messing up your setup trying an experimental build!
Here is an example, using wget's recursive capabilities for simplicity once again:
wget -nv http://my.opera.com/desktopteam/blog/ -O - | grep snapshot.opera.com\/unix | head -1 | sed -e "s/.*\(http.*\)\" target.*/\1/" | wget -i - --spider -r -erobots=off -nd -np 2>&1 | grep \/opera.*.gcc4.*qt3.i386.tar.bz2 | sed -e "s/.*http/http/" | wget -i - -O - | tar xjf -
Note: In this example I use the '--spider' option. Although this option has been around a while, a bug in older versions mean that my intended usage would fail. However it does work with the version found in most modern distros (1.11.4) and the very latest version (1.12).
If the above fails for you because you have an older version of wget, here it is without making use of '--spider' or recursion. I'll use the same technique as in my curl example but this time using wget once again:
wget -nv http://my.opera.com/desktopteam/blog/ -O - | grep snapshot.opera.com\/unix | head -1 | sed -e "s/.*\(http.*\)\" target.*/\1intel-linux\//" | wget -nv -i - -O - | grep -e title.*intel-linux -e gcc4.*qt3.i386.tar.bz2 | tr -d '\n' | sed -e "s/.*\(.unix.*linux\).*a href=\"\(opera.*bz2\)\".*/http:\/\/snapshot.opera.com\1\/\2/" | wget -i - -O - | tar xjf -
Of course writing an actual script rather than a one liner would allow for error checking, only downloading if a newer version is actually available, and so on. And before anyone asks, no I won't be creating such a script and sharing it!

Finally, let me remind you all to read the associated snapshot blog post before installing any build, so that we can highlight known issues and major problems. If you don't and something goes wrong, you can only blame yourself!














Sveinsvein # Friday, October 2, 2009 10:04:47 AM
Ruarí Ødegaardruario # Saturday, October 3, 2009 2:21:38 PM
abhrapro # Sunday, October 4, 2009 2:18:13 PM
Ruarí Ødegaardruario # Wednesday, October 7, 2009 6:39:19 AM
Note: You will get rather a lot of output during the download. This is related to wget recursing through each of the subdirectories checking for the appropriate package of Opera to download. This could be avoided by adding the command line option -q to the end of any of these examples but then you will get no feedback of download progress. Alternatively you could use a non recursive method as I have outlined above.
FreeBSD 6 Intel/i386
freebsd6-shared-qt3.i386.tar.bz2:
FreeBSD 6 amd64
freebsd6-shared-qt3.amd64.tar.bz2:
FreeBSD 7-8 Intel/i386
freebsd7-shared-qt3.i386.tar.bz2:
FreeBSD 7-8 amd64
freebsd7-shared-qt3.amd64.tar.bz2:
Linux G2 (gcc3-qt3) Intel/i386
gcc3-shared-qt3.i386.tar.bz2:
gcc3-shared-qt3.i386.tar.gz:
gcc3.shared.qt3.i386.rpm:
gcc3.qt3_i386.deb:
Linux G3 (gcc4-qt3) Intel/i386
gcc4-shared-qt3.i386.tar.bz2:
gcc4-shared-qt3.i386.tar.gz:
gcc4.shared.qt3.i386.rpm:
gcc4.qt3_i386.deb:
Linux G4 (gcc4-qt4) Intel/i386
gcc4-bundled-qt4.i386.tar.bz2:
gcc4-bundled-qt4.i386.tar.gz:
gcc4-qt4.i386.tar.bz2:
gcc4-qt4.i386.tar.gz:
gcc4.qt4.i386.rpm:
gcc4.qt4_i386.deb:
Linux G3 (gcc4-qt3) x86_64
gcc4-shared-qt3.x86_64.tar.bz2:
gcc4-shared-qt3.x86_64.tar.gz:
gcc4.shared.qt3.x86_64.rpm:
gcc4.qt3_amd64.deb:
Linux G4 (gcc4-qt4) x86_64
gcc4-bundled-qt4.x86_64.tar.bz2:
gcc4-bundled-qt4.x86_64.tar.gz:
gcc4-qt4.x86_64.tar.bz2:
gcc4-qt4.x86_64.tar.gz:
gcc4.qt4.x86_64.rpm:
gcc4.qt4_amd64.deb:
Linux G3 (gcc4-qt3) PowerPC
gcc4-shared-qt3.ppc.tar.bz2:
gcc4-shared-qt3.ppc.tar.gz:
gcc4.shared.qt3.ppc.rpm:
gcc4.qt3_powerpc.deb:
Solaris Intel/i386
gcc4-static-qt3.pkg.Z:
gcc4-static-qt3.pkg.bz2:
gcc4-static-qt3.pkg.gz:
gcc4-static-qt3.tar.Z:
gcc4-static-qt3.tar.bz2:
gcc4-static-qt3.tar.gz:
Solaris SPARC
gcc4-static-qt3.pkg.Z:
gcc4-static-qt3.pkg.bz2:
gcc4-static-qt3.pkg.gz:
gcc4-static-qt3.tar.Z:
gcc4-static-qt3.tar.bz2:
gcc4-static-qt3.tar.gz:
Ruarí Ødegaardruario # Thursday, October 8, 2009 7:56:21 AM
Latest Beta or Final (Linux G3 Intel/i386 .rpm package):
Latest Final only (Linux G3 Intel/i386 .rpm package):
Note: If you wanted you could change the 'gcc4.*qt3.*i386.rpm' part to match your own favoured package.
As some of you will probably notice, prior to the 10.00 release a simple sort would not been enough to deal with selecting the highest version number in the 'pub/opera/linux' directory (964 would have appeared more recent than 1000, as 'sort' only considers the first digit), and two packages would have been matched by the regular expression 'gcc4.*qt3.*i386.rpm' (the regular and the static build). Both issues have easy workarounds but they are not needed any more, so I have not even tried. Nonetheless these types of changes clearly demonstrate that with the longer release cycle of Betas and Finals, such simple scripts could easily break before you manage to download many updates.
These problems can be negated to an extent by running, two commands. The first just echoes back the name of the package that would be downloaded if you ran the second (just take '| wget -i -' off the end of one of the examples above to create such a command). This allows for a quick visual check that everything looks correct prior to committing to actually downloading your update. If you see an obvious problem after running the first command, you can just download manually from www.opera.com/download or ftp.opera.com/ instead.
Realistically however, given the infrequency of major releases, maintaining such scripts may waste more time than just manually downloading Opera (and if you are using a Debian based distro and want Qt3 packages, you would be wasting your time entirely given that we have an official APT based repository that offers these). So whilst these types of tricks are handy for snapshots they are arguably less useful for Betas and Finals.
Ruarí Ødegaardruario # Wednesday, October 14, 2009 12:02:24 PM
Anyway as of 14/10/2009 the "Latest Final only (Linux G3 Intel/i386 .rpm package)" grabs opera-10.00.gcc4.shared.qt3.i386.rpm and "Latest Beta or Final (Linux G3 Intel/i386 .rpm package)" grabs opera-10.10-b1.gcc4.shared.qt3.i386.rpm.
It will be interesting to see for how many updates this continues to work!
abhrapro # Friday, October 16, 2009 1:54:41 PM
Unregistered user # Tuesday, November 10, 2009 4:37:43 PM
Ruarí Ødegaardruario # Tuesday, November 10, 2009 4:45:53 PM
Thanks for the input!
quarkup # Tuesday, November 10, 2009 9:50:01 PM
i solved my own problem with the 'qt-bundled' package and filled a bug report (as you can see here).
thanks for giving me the right direction.
Ruarí Ødegaardruario # Sunday, November 22, 2009 9:49:42 AM
You can fix them by sending an Opera user agent. In Wget use the '-U' command line argument and in cURL '-A'. For convenience this is the current Opera user agent for Linux on Intel: "Opera/9.80 (X11; Linux i686; U; en-GB) Presto/2.2.15 Version/10.10"
I'll investigate on Monday to try and find out if this was intentional by the My Opera Team or not.
P.S. We released Opera 10.10-4742 (RC6) yesterday.
Ruarí Ødegaardruario # Sunday, November 22, 2009 11:51:27 AM
You can find his G4 (gcc4-qt4) PKGBUILD and a G3 (gcc3-qt4) version based on this via the links below:
opera-g3
opera-g4
arghwashier # Tuesday, May 11, 2010 9:19:11 AM
[Edit by ruario: Removed example bash script]
Ruarí Ødegaardruario # Tuesday, May 11, 2010 11:01:42 AM
1. I do not recommend downloading a snapshot before it is publicly announced. It is a bad idea because if we find a really serious last minute issue prior to making a snapshot public then we pull the build from the server. Using that script, a user could end up with a build that contains such an issue.
2. Your script would hammer our server with requests until the user manually stops it. This isn't so much a problem with one user but it becomes a problem if several users start to use the same script (particularly if they don't switch it off).
Use one of the following instead to grab the latest 10.5x (Evenes) snapshot for your *nix OS and processor architecture, in your preferred package type:
Linux 32bit Intel/i386 .tar package:
Linux 32bit Intel/i386 .rpm package:
Linux 32bit Intel/i386 .deb package:
Linux amd64/x86_64 .tar package:
Linux amd64/x86_64 .rpm package:
Linux amd64/x86_64 .deb package:
Linux PowerPC .tar package:
Linux PowerPC .rpm package:
Linux PowerPC .deb package:
FreeBSD 32bit Intel/i386:
FreeBSD amd64:
You could make a more complex script that first checks if you have already downloaded the build but to be honest it is probably just as easy to subscribe to the desktop team RSS feed and when you see that a new build is announced run one of these one liners. To save you the hassle of typing out the whole command each time either make a shell alias or place it within an executable text file to make a one line script.
Ruarí Ødegaardruario # Monday, January 10, 2011 6:57:21 AM