How I live without shell job control
In my comments on yesterday's entry, I mentioned that my shell doesn't support job control. At this point people who've only used modern Unix shells might manage how you get along without such a core tool as job control. The answer, at least for me, is surprisingly easily (at least most of the time).
Job control is broadly useful for three things: forcing programs to pause (and then un-pausing them), pushing programs into the background to get your shell back, and calling backgrounded programs back into the foreground. In other words, job control is one part suspending and restarting programs and one part multiplexing a single session between multiple programs.
It's possible that I'm missing important uses of being able to
easily pause and unpause programs. However, I'm not missing the
ability in general, because you can usually use
SIGCONT by hand. I sometimes wind up
doing this, although it's not something I feel the need for very
(I do sometimes Ctrl-C large
makes if I want to do something
else with my machine; with job control it's possible that I'd
make instead and then have it resume afterwards.)
My approach to the 'recover my shell' issue is to start another
shell. That's what windows are for (and
screen), and I have a
pretty well developed set of tools to make new shells cheap and
easy; in my opinion, multiple windows are the best and most flexible
form of multiplexing. I do sometimes preemptively clone a new window
before I run a command in the foreground, and I'll admit that there
are occasions when I start something without backgrounding it when
I really should have done otherwise. A classical case is running
emacs file' (or some other GUI program) for what I initially
think is going to be a quick use and then realizing that I want to
emacs running while getting my shell back.
(This is where my habit of using vim in a terminal is relevant,
since that takes over the terminal anyways. I can't gracefully
multiplex such a terminal between, say, vim and
make; I really
want two terminals no matter what.)
So far I can't think of any occasions where I've stuck a command into the background and then wanted it to be in the foreground instead. I tend not to put things in the background very much to start with, and when I do they're things like GNU Emacs or GUI programs that I can already interact with in other ways. Perhaps I'm missing something, but in general I feel that my environment is pretty good at multiplexing things outside of job control.
(At the same time, if someone added job control to my shell of choice, I wouldn't turn my nose up at it. It just seems rather unlikely at this point, and I'm not interested in switching shells to get job control.)
Sidebar: multiplexing and context
One of the things that I like about using separate windows instead of multiplexing several things through one shell is that separate windows clearly preserve and display the context for each separate thing I'm doing. I don't have to rebuild my memory of what a command is doing (and what I'm doing with it) when I foreground it again; that context is right there, and stays right there even if I wind up doing multiple commands instead of just one.
(Screen sessions are somewhat less good at this than terminal windows, because scrollback is generally more awkward. Context usually doesn't fit in a single screen.)
PS: the context is not necessarily just in what's displayed, it's also in things like my history of commands. With separate windows, each shell's command history is independent and so is for a single context; I don't have commands from multiple contexts mingled together. But I'm starting to get into waving my hands a lot, so I'll stop here.
Comments on this page:Written on 25 September 2016.