Why Are Multiple Shell Instances Necessary?

Question

I usually run 10--12 terminals at any given time, and this doesn't take up to much memory since I can use the rxvt-unicode daemon urxvtd.
Yet each terminal has its own instance of bash, and this does take up memory.
What I wonder is whether it is really necessary for each terminal to have its own shell instance.
Obviously this is a necessity for independent history, but I really don't care too much about that.
Is there a way to run a bashd and have the individual shells hook into it? Is it even possible, or is there some consideration I have failed to make?
Maybe my workflow is flawed, I don't know.
My OCD nature prevents me from opening and closing terminals as whim, as there is a predetermined place for everything to go.
I always have the same terminals for their same respective things open on each workspace.
Some of them really don't need a complete shell though... for instance I have one to update svn and read commit logs, one for irc, and another for file transfer on my net workspace.
None of these need bash's features... I know I don't need bash underneath irssi but I do need some sort of command prompt to run my svn scripts and transfer programs.
In fact it seems most of my shells are more like command launchers, though I do want to see the output and be able to scroll back. Perhaps another shell would be better for me.
Only in a couple of my terminals do I actually use globbing and piping and such --- this is where bash is a necessity.
Of course if there was a way to hook the shells into one instance, I wouldn't feel so guilty about having so many open for so little purpose.
Also, I still don't know how to use a single terminal multiplexer, so obviously I will look into screen or tmux.
Any recommendations or insight would be greatly appreciated.
EDIT: I now know that it isn't possible to have a shell daemon, and I realize that my concern over memory usage is considered unfounded. Now I would like to know why no such program is available / why it's impossible. This is for my education.
Last edited by egan (2010-07-05 16:48:01)

Answer 1

karol wrote:
@ egan
You can background apps: bg, fg, jobs etc.
> where the stdout goes
It goes where you tell it to go, you can always redirect.
Yes I know job control and such, I don't really see how that is related.
I know where stdout goes and how to redirect it --- I just wondered if that was a possible consideration as to WHY it is necessary for multiple, complete shell instances.
Why is it not possible to have one shell managing things with clients (in different terminals) hooked into it to give it commands?
Another consideration I realize is that blocking processes (not backgrounded or immediately returning) would preclude the clients from communicating with out the shell forking?