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 urxvtd and 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. 😉
Motho ke motho ka botho 
Nice, I hadn’t heard of that trick. 🙂
In the “lighter shell than bash” department, you could always compile a minimal bash, or even use dash. 😉
Pingback: Using dmenu with xft fonts « Motho ke motho ka botho
You could always use zsh, though I’m not sure how that relates to bash in terms of memory usage. It certainly provides me some extremely useful perks (smart auto-completion, correction of incorrectly typed commands, suffix matching, AWESOME globbing abilities etc.)
It’s funny – I’ve used urxvtd and urxvtc for a while – even on a system with 4GB RAM. (I’m a graphic designer and Adobe’s apps are notoriously RAM hungry) It simply makes sense to me, I suppose, to have a daemon that controls all of my term emulators.
QUOTE
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.
/QUOTE
That is not true.
You can always invoke a command like this:
xterm -e /usr/bin/vim
from some menu or shortcut of your desktop, and you will get a terminal application running under a X terminal, WITHOUT bash or any other shell.
You can replace xterm with your favourite X terminal, but you need check if the option is also named “-e”.
You’re right; sorry. I didn’t do a very good job explaining that when I wrote it.
The other alternative, although I am not sure of the exact memory hit, would be use one xterm with screen?
Pingback: X and Openbox in 12Mb « Motho ke motho ka botho