GoboLinux 014 is now officially released, after a few quiet release candidates. Check it out, you’ll like it.
Archive for December, 2007
Having already posted some GoboLinux-specific scripts, this time I’ll do some of the others I find useful that aren’t tied to a particular distribution.
- lpr is a replacement for the lpr provided by CUPS or otherwise that prints to a PDF. It’s useful for working on a laptop that may not have a printer available directly all the time, or for making PDF exports from programs that don’t provide that directly. My principal use for it is printing to a PDF to be taken on a flash drive to a system that does have a printer attached, and to save a copy of something I may want to print a duplicate of at a different place or time.
It’s a fairly simple script. It allows you to specify a mountpoint for your flash drive (NFS share, SSHFS, …), where the generated PDF will be put. If the mountpoint doesn’t exist, the file goes into /tmp, so it works for transient mounts as well. Generated filenames are of the form ‘YYYYMMDDHHMMSS.pdf’. The script depends on ps2pdf13 being available – substitute another version or plain ps2pdf if you want (it’s part of Ghostscript). It also calls a script called “notify” to display a message informing you of the print and what it’s called: it’s optional, so you can delete that line if you want, but it works with the script I’m going to post below.
- notify is that script. This version uses knotify, so it requires you to be running KDE. It takes two parameters: the first gives the title of the transient message displayed, and the second its content. An alternative version takes the whole argument list as the message content. This one’s mostly useful for calling from other scripts. Change the “16 0 1” parameters at the end to get different behaviour out of knotify.
- xri resolves an XRI/i-name to a URI, using the xri.net resolver, and outputs the final URI after following all redirects. Usage is simple, for example:
xri @example/+blog– if there’s no global specifier present, it assumes a personal i-name, so
xri mwhwill work, if you’re using a shell where “=mwh” is a path lookup. How useful this is depends on how often you deal with i-names and what you’re wanting to do with them. I still find them a little dubious myself, but the contact service is nice when I’m posting scripts like this and don’t want to put my email address out to be harvested, and they do seem well-intentioned, so I guess we’ll see how they go. But that discussion’s for another day.
This script depends on curl, but could be adapted to work fairly easily with anything able to make a HEAD request (wget is difficult, since it always follows Location: headers, but anything better-behaved would work).
- twitter sends twitter messages (!). All the parameters on the command line are used for the message, so
twitter This is a tweetwill send “This is a tweet”. The first time you run it, you’ll be prompted for your twitter username/email address and password to use. They are saved into ~/.twitter if you want to change them later (it’s sourced as a bash script, so edit accordingly, or just delete it and you’ll be prompted again next time). This one also depends on curl, but adapting it to use wget –post-data= would be pretty trivial. The URL-encoding used is a little excessive, and %-encodes every character, so if somebody can come up with an equally concise method that doesn’t I’ll update the script. It is legal (and works) as it is, but it’s not very clean to have things like “%54%68%69%73%20%69%73%20%61%20%74%77%65%65%74” go through the wire unnecessarily.
As last time, I’m posting these scripts in the hope that they will be useful, but without any warranty that they’ll work or not break things. They’re available under the GPLv3+, and any improvements anybody makes to them will be welcome if sent to me. If anybody wants them relicensed for some reason, be in touch too and I’ll consider it.
cosminap made an interesting post in the forum about “snapshotting” a GoboLinux system (the relevant part is at the end of the post). S/he suggests using a union filesystem to do so magically, and also do away with patching of programs to fit the filesystem hierarchy (a common thread from earlier posts: I don’t think it’s necessary or terribly useful. I might make a longer post later). However, there’s also a suggestion of doing the same thing by making copies of the /S/L tree and creating a symlink to the newest version, which I think is viable.
I did a little testing on my dummy system, and there’s nothing in Scripts that requires the entries under /System to be real directories
Making additional copies and switching the symlink around will let you have pretty effective snapshots of your system state. It isn’t as simple as cosminap suggested, though: as I said, kernel modules must be installed in a real path, and aren’t under the /S/L hierarchy, and neither is the kernel, one of the examples in the post. Unmanaged files in general would only be updated with a SymlinkProgram run. Settings can also change between versions and wouldn’t be covered, nor would /Programs/*/Current. So it would mainly be useful as a recovery method from a single broken install, rather than a full system snapshot, and in that case you’d know what was wrong and be able to revert it yourself.
What cosminap really wants here is a full snapshotting filesystem, like ZFS. It’s only available through FUSE for Linux, so it’s probably not as performant as you’d like for your root filesystem. I remember hearing that NTT made a native filesystem with similar functionality, but I couldn’t find it just now. That’s a better level to implement this than in the system tools, given the range of changes that can be made, and the need for the restored system state to be consistent. The filesystem or dedicated backup software is where this belongs.
Here’s a couple of handy scripts I use that work with the GoboLinux distribution, that I find useful but that probably aren’t useful enough to be in core. I keep them in /Programs/LocalScripts along with a few others, but they work as well in ~/bin or elsewhere. They should both work in Rootless within another distribution, but I haven’t tested that (reports welcome).
- OldPrograms searches your /Programs tree for outdated versions of programs that are still installed. It also outputs the total size of each outdated version and of all outdated versions of each program. It can also print a list of pathnames suitable for saving or piping elsewhere, or execute a command on each such path.
OldPrograms --helpprovides more details on those options. It requires BC to be installed, and bash to be accessible through /bin/bash.
SuggestDuplicates does much the same thing slightly differently, and is in Scripts, so you might prefer that. The major differences in functionality are that OldPrograms calculates more detailed disk totals and supports executing an arbitrary command; SuggestDuplicates produces output suitable for executing at the shell to remove or disable a program and runs faster. I will probably merge the two at some point, and would have from the start if I’d found it then.
- NewLocalRecipes finds local recipes that are newer than the versions in the store, or for programs that have no recipes so far. It was first written in response to a request on gobolinux-users, as a long shell command, but I’ve found it useful and cleaned it up into a script. It has no special dependencies beyond the basic system.
I’m posting both scripts in the hope that they will be useful, but without any warranty that they’ll work or not break things. They’re available under the GPLv3+, and any improvements anybody makes to them will be welcome if sent to me. I have a few other scripts in LocalRecipes, but they aren’t Gobo-specific so I’ll keep them for another time.
Update: a third one I forgot
- rurl outputs the URL(s) in the recipe for the provided program. It’s useful for scripting mass fetches of archives with xargs, or for getting a valid URL automatically rather than having to replace $httpSourceforge and $ftpGnu manually.
This is the first of hopefully many posts, and a test of how well the system’s set up at this point.