poll: when you're using your shell **interactively**, do you ever use its job control features (ctrl+z, fg, bg, `jobs`, `wait`, etc?)

(other than maybe occasionally backgrounding a process with &)

yes, frequently
23.1%
yes, occasionally
36.8%
never (or almost never)
39%
other
1%
Poll ended at .

I'm also curious about reasons folks are using job control instead of opening a new tab in their terminal/tmux/screen

so far we have:

* use ctrl+z to suspend a CPU-hungry program because you need to use the CPU for something else
* you're in a situation with no screen/tmux/fancy terminal
* background a GUI app so it's not taking up a terminal tab
* accidentally started a long-running job without tmux/screen
* already set up a lot of environment variables
* accidentally ran ctrl+z

(2/?)

@b0rk

Often: ctrl+z to see what is running on that terminal, exactly. Particularly useful for programs that run over many hours or days.

@albertcardona interesting -- do you run programs that run for many days without using screen/tmux?
@b0rk
Ya,
@albertcardona why not screen?! 😁 Although I have to admit sometimes I get carried away outside of screen and do similar things.

@kisharrington @b0rk

'screen' is very useful – it's a default for me. But often launched programs are GUI-based in some way, and I need to see with how much RAM I launched them, and what exact parameters.

@albertcardona @b0rk aha, touche! that makes a lot of sense, especially for JVM args and such

@b0rk

Even when using screen/tmux, I still need to remember which one is which. And yes I run programs for tens to hundreds of hours, sometimes – to assemble multi-terabyte image volumes from 2D image tiles.

@b0rk I don't like having a whole terminal kicking around for a long running background process (eg a gui I've launched from the command line)

@b0rk

Sometimes it is quicker to ctrl-z out of `vim` and then run `make` and then `fg`.

@b0rk Additional windows/tabs mean additional mental overhead. I really, really, do not like more than 2 terminal windows active at a time.

@b0rk For me, a major factor is a single history, unlike screen/tab.

A secondary reason is knowing that the same terminal is definitely on the right machine (SSH). Yes, screen works, but especially if it's nested, or if you're not 100% sure, Ctrl+Z just feels easier sometimes.

@b0rk Because I'm frequently using remote machines via ssh. Opening a new window and ssh'ing again into that machine is a lot more faff then using ctrl-z + bg.
@ives thanks! do you prefer using ctrl+z/bg/etc to something like screen/tmux?
@b0rk screen/tmux are nice tools, but you need to start those beforehand. ctrl-z/bg is nice when you started a cmd and it's taking longer than expected.

@b0rk Yeah, "start a GUI and retroactively decide I want to background it" is the most common reason I do it.

But then why don't I just open a new terminal?

Well, usually it's because there's some amount of state in the existing one. Activated virtualenv, history that won't be available in a new terminal, variables that are set with API tokens, etc.

Also, I usually have way too many terminals/tabs open at once, avoiding having another one to keep track of helps to avoid further sprawl.

@b0rk create new namespaces associated with a shell and leave it in the background to use in a local “lab environment”
@grabbi_it what do you mean by namespaces?
namespaces(7) - Linux manual page

@b0rk forgot to launch tmux/screen after remoting in and starting a long-running job, is usually it
@b0rk (I do this maybe two or three times a day, I am good at my job I swear)
@cawhitworth thanks this is a great one
@cawhitworth @b0rk I made a `screento` script to automate that for me
(still have to remember to use it tho)
@ShadSterling @cawhitworth @b0rk care to share it?
@bilbo_b @cawhitworth @b0rk I wish we had a shell with a package manager where I could publish such things, but since we don't I made a gist: https://gist.github.com/ShadSterling/a205e0037b33892fe15ca3e85df37b3d
~/bin/screento

~/bin/screento. GitHub Gist: instantly share code, notes, and snippets.

Gist

@b0rk ctrl+z
bg
disown
exit

To let a task continue without staying connected. But that also kinda falls under the second option I guess

@b0rk Usually? I've set a load of environment variables as I'm doing something and it's easier to background something that's running and run another command than to remember what I'd set.

It's absolutely a problem of my own making, and if job control didn't exist then I'd keep a dotfile up-to-date, but it does and I don't.

I've had the "no screen/tmux" etc. thing in the past where I'd SSH in somewhere, open an editor to change a config, ctrl+z, restart service, test, etc. - I just found the muscle memory of `ctrl+z, up, up, enter, ctrl+r resta, enter, <test>` loop really easy.

Again, making work for myself, but you know what it's like when you're in the middle of something- the most efficient way of working is whatever you've done a hundred times before.

@b0rk I voted rarely/never, but when I did use it then it was because I had a local test server that ran multiple micro services in seperate screens. A single script launched them all and laid them out in a consistent fashion.
@b0rk I accidentally started the process outside of screen and it's been going three hours and now I need to close my terminal but not terminate the process
@b0rk on smaller screens, a whole new window/workspace can be more of a context switch than ctrlz, command, fg. Depends if I need to come back and reference the second terminal.
@b0rk often I tend to use a lot of loops, pipes, etc. on the command line. The long running command that I suspend is often hogging a shell that has some complex command that I ran earlier and need to run again.
@mgerdts thanks! is the point here that you can't retrieve the complex command you ran earlier in a different terminal? (because of the way bash handles history?)
@b0rk yep. When I used some other shell (ksh?) that shared history between terminals, I was much less happy.
@mgerdts oh interesting, can you say why? I really appreciate the way my shell (fish) shares history between terminals and I'm curious about why the way ksh did it didn't work for you
@b0rk it’s been a while, but I think it was because what I got from hitting up arrow in one terminal varied by what I (or someone else, in the case of shared accounts) typed in some other terminal. It’s a great way to get an overly broad rm in the wrong directory.
@mgerdts thanks that makes sense! Sounds pretty dangerous. I really appreciate fish's approach (where when you open a new terminal, you'll get all the history from every other open terminal, but if you run a command and press up arrow, you'll only get the command you just typed)
@b0rk I usually use it when I'm interacting with an embedded device that supports job control but doesn't have tmux/screen installed.
But also, sometimes I just need to drop out of an editor to run a quick command or two in the current directory, and it's faster/easier than launching yet another terminal or pane.
@b0rk I often use suspend to check on some output I got from a command I ran just before I opened a fullscreen terminal application (e.g. nano).
@b0rk I often ctrl+z because I did something like long-running-command but I want to make it do something after it finishes when I might not be around, so fg && shutdown or similar.

@b0rk At my company they don't allow terminal/tmux etc so you have to use bg/nohup/& if you want to start a long running job and be able disconnect your session.

As an aside I've found a way around the tmux ban by compiling a version to run out of my home directory which has been working fairly well.

@b0rk
No, but I want to do it in the future.
@b0rk TBH I don't really see the point in ctrl-z and bg/fg when I can just... Open another terminal.
I use Ctrl + z and fg occasionally, mostly to suspend a CPU-heavy task for a little while because I need the CPU for something else or want the fans to be silent.

Pitfall: Ctrl + z breaks loops (for/while), the current iteration of the loop can be resumed but the next iterations will never run.

@b0rk Not only do I often use `jobs`, but I also use the `%` syntax for job numbers a lot. So quite often I'm glad that I wasn't root, because I tried to `kill %1` and mistyped it as `kill 51`.

PID 51 is usually something like a CPU hotplug thread in the kernel, these days.

@b0rk

I haven't done that in a long time, ... because we have windows.

@b0rk not sure where the line is between "occasionally" and “almost never", but picked the former because it was only yesterday I did a ctrl-Z…fg to pause an ffmpeg while I did something else needful of CPU time. But previous time before that, can't remember.
@StrangeNoises thanks, that's a great example of a reason to use ctrl+z!
@b0rk
before screen (or tmux), I used job control features all the time. After I started using screen (or tmux), it replaced job control in nearly all instances. Actually I can't think of any exceptions.
@b0rk I used to use these more frequently, but now I use tmux to do all of this in a way that’s easier for me.
@b0rk `ctrl+z bg && disown` was one of the first bash features I ever learned and it's always stuck with me, though I use it far less often now that I'm a "professional" software engineer instead of a computational scientist.
@b0rk I am more likely to open another console tab, or use screen, because it's easier to track my different activities when I can see them easily. But sometimes you don't have those options, like when troubleshooting in single-user mode, or through a remote server's serial console. Then I find those job control features *very* handy.
@b0rk frequently, but only to start gui apps (such as gitk) and then deciding that I want them in the background and continue to use my shell, so ctrl+z and bg
@pulkomandy thanks, that's a great example

@b0rk I use ctrl-z and fg a lot, especially with vim.

It's so easy to edit some config then ctrl-z and `systemctl restart foobar`.

@b0rk is there an explanation what are "its job control features". I think I wasn't at school on that day 😔

@xgebi yeah they're a little bit obscure! it's a set of features that let you:

* stop a program and resume it (ctrl+z)
* move a process from running in the foreground to the background
* run multiple programs in the same terminal, see which ones you have running right now, etc

it's a bit weird because these features were invented before we had screen/tmux/terminal emulators with multiple tabs, so some of the problems it solves aren't problems anymore in the same way most of the time