Interesting, but by way of dmenu, I discovered something I wish I had known a long time ago: That there is a daemon available to rxvt-unicode, which will allow you to run multiple terminal instances with a slimmer memory footprint and quicker spawning times.
I have always resented the fact that my terminal-based systems running under X incur a rather hefty price in the way of one instance of urxvt per application, which in turn implies one instance of bash per application. (One of these days I’ll get off my rear end and pick a shell that isn’t quite as hefty, relatively speaking, as bash. Suggestions welcomed. )
I had been using dmenu in Musca to start applications with
urxvt -e (application), and each time I saw options for both
urxvtc. A quick skim through some man pages, and now I understand that urxvtd is the daemon, and urxvtc triggers the daemon to spawn a new terminal window.
Which means that instead of four terminal emulators taking up a wide slice of the 16Mb I have in this Pentium, I have one daemon running and four applications hooked into it.
Why bother? Well for me, as I have already implied, the amount of space required is suddenly a fraction, inversely proportional to the number of emulators you originally needed. (That makes almost no sense at all, but suffice to say that when I ran tty-clock, centerim and hnb alongside charm, I used to need four terminals and four instances of bash to run them. Now I need only one daemon, which I suppose suggests it takes up one-quarter of the resources. … )
Now that we have settled the why, here’s the how: On an ultralight system or any system that relies on .xsession or .xinitrc (which suggests Openbox, et al.), insert this line to the .xinitrc file.
urxvtd -q -o -f
The q flag spares you the startup notification. The o flag picks the open X display and the f flag forks the daemon and takes it out of your way.
Now, whenever you spawn a terminal window, use
urxvtc instead of
urxvt, and the running daemon will hand you another terminal prompt.
There is a downside to this (there always is, isn’t there?): If the daemon dies, all the applications hooked to it can suffer the same fate.
For me, running that risk is worth it, for two reasons. First, this machine has so little memory to spare, that the 1 or 2 megabytes I save by eliminating the one-emulator-per-application is significant.
Second, the time it takes to open a new prompt is likewise reduced. I recompiled Musca to link the
urxvtc command to the
Mod4+t key, and now the daemon sprouts a new prompt in a fraction of the time it used to swap out the memory and start a whole new emulator.
I realize this is hardly news, and it’s hardly interesting to anyone who’s not using terminal applications as a matter of course. I probably wouldn’t even bother using this on my Openbox systems just because I don’t use enough terminal applications on those to warrant setting it up.
On the other hand, if you’re a bottom-feeder like me, you will claim back a sliver of memory and a smidgin of start time by relying on the daemon, instead of one emulator per application.