what are some problems with quitting programs in the terminal you’ve run into? so far I have:

- not knowing how to quit vim (or some other program like nano etc)
- programs not responding to ctrl c
- a background program being killed when you close your shell

what am i missing?

@b0rk I never remember how to exit nano despite the commands literally being printed on the screen at all times. Too many decades of vim/emacs

@zrail @b0rk the ONLY magic incantation I have to remember for the rest of my life to get out of the darkest places is - escape, colon, Q, exclamation-mark, enter

the rest is easy, the rest is straightforward and intuitive, just as calming as a lullaby...

@b0rk accidentally backgrounding a task that prints to stdout/stderr
@stormsweeper @b0rk or backgrounding a task that reads from stdin and thus gets paused
@b0rk it’s not super common but I have seen various development servers (Python, node) get mysteriously disconnected from their process group and just hang out until I notice and kill -9 ‘em. Usually manifests as a port conflict when I start something up.
@b0rk maybe not restoring the terminal to a good state? (Needing to run reset etc)
@AndrewMcHarg @b0rk nslookup is notorious for this, I had to look up and memorize stty sane simply for it after years of pain
@b0rk I used to get really confused by programs not exiting when i ran `kill $pid` (not knowing about kill -9 / not realizing that kill is "send a signal" more than "stop this thing", etc)
@eieio @b0rk It’s so obvious, though: KILL: “Kend It Le signaL”
@eieio thanks!

@b0rk thinking about it more, I guess my `kill` confusion is basically the same as the "programs not responding to ctrl c" that you mentioned. both are just sending a signal that I used to assume was "close the program" but it's a little more complicated than that.

I'd never considered that before though!

@b0rk On the theme of background programs: accidentally pausing something with Ctrl+Z when I meant Ctrl+C and not knowing how to get it back.
@samir @b0rk Something similar: Backgrounding a graphical application with Ctrl+Z, forgetting that I did it and then thinking that the application just froze. This mostly happens because I forget the & to start them in the background in the first place.
@samir I guess you already know it, but usually a simple fg does the trick. Or fg %1, fg %2 – the jobs command will tell you the number.
@notbobbytables Yep, I am now intimately familiar with bash job control. I'm not sure whether I'm proud or horrified about this. :-p
@b0rk Accidental Xon/Xoff can be very confusing. Also maybe backgrounding a process
@b0rk - no response to kill <pid>
@b0rk Ctrl-S / Ctrl-Q ?
@mhd @b0rk omg yes this, so much. It's just a fatfinger usually and your program is totally, inexplicably stuck!! And actually there's nothing wrong, you just need to *know* about ctrl-q...

@b0rk

a background program writing stderr to the terminal while I'm trying to do something else

@b0rk

e.g. I thought it was closed but...

@b0rk Needing to use kill -9, programs that get respawned by their parent after terminating, and determining which one of several similar processes to kill.
@b0rk you just logged into a machine you expect to have bash or zsh and you accidentally run a built-in command like ls which launch a program you don't know how to leave. This works on openvms default shell

@b0rk Sometimes if C-c doesn't work I'll C-z. In theory, 'jobs' shows that job, but I don't know how to kill from there.

So I use ps | grep, but it can be a hassle.

And if there's a subprocess, I get <defunct>s and a mess.

@davidr @b0rk C-\ is usually the right move if C-c doesn't work. C-z tends to just send stuff to the background.
@wyatt8740 @b0rk Huh, I've never heard of C-\. I'll try to remember that one
@davidr @b0rk it sends SIGQUIT which is stronger than SIGINT. :)
C-d for SIGHUP can also be useful to try but sigquit is more likely to worki.
@davidr @b0rk for the record:

$ kill -9 %1

will kill the first backgrounded job.
@davidr @b0rk also when I was first learning I suffered the inverse - I was trying "undo" and typed ctrl-z, thereby sending vim into the background, and I had no idea how to bring it back!
@stephen @b0rk MS hijacking C-a to "select all" when I want to edit the beginning of a line has lost me a LOT of email bodies.
@b0rk I keep forgetting all the commands that would make things less tedious. Like I remember ctrl a for going to the start of the line but somehow can’t remember the ones about going to the end, or going word by word, or clearing the line

@skinnylatte
Same ...but Adrianna did you know: option + click puts the terminal cursor wherever you choose on the line?

Maybe you did but that trick is still gold to me
@b0rk

@b0rk not quite the same thing, but I still surprise myself pressing ctrl-z absent mindedly in a vi or other editor session expecting it to undo my action and instead it backgrounds the program. The first many times I did that I had no idea why the editor went away.
@b0rk The third one is not like the others. Read up about the nohup utility (and possibly about the setsid() and setpgid() syscalls).
@riley as usual not looking for people to explain these to me (i know why it happens!), just more problems
@riley @b0rk A user survey is not a request for help.
If you disagree, try writing "I think you should already know this" as the answer to any exam question.
You will be right! and also score zero.
@b0rk there's the issue that you might think you've quit the program, but it has left around child processes that become zombies, which might still be doing the task you thought you stopped
@d6 ugh yea this is such a good one thanks
@b0rk "broken" terminal (+1 for @AndrewMcHarg), e.g. after using screen; sometimes stty sane helps
@tamberg @b0rk @AndrewMcHarg this - sometimes if I cat a binary file by accident, the terminal gets into a totally weird state. i usually use the "reset" command. (not about quitting programs strictly speaking, apologies)
@hjwp @tamberg @b0rk I have done this more times than I can count 🤣. Usually it’s me thinking it might be binary but gambling on my terminal it is not.
@b0rk Scripts or complex pipelines where ^C just kills one program, and stuff keeps running and you keep hitting ^C.
@jani @b0rk for script you can Ctrl+Z + kill. Haven't found a trick for complex pipelines.
@b0rk Programs that leave your terminal in a weird state. Like, they do some graphical things, but don't undo them, leaving the characters "corrupted" or the cursor invisible.
@b0rk sometimes if a program isn't responding to Ctrl+C I can still break out with Ctrl+Z and kill the job, but sometimes that won't work either

@b0rk a fun one: https://mastodon.social/@boldewyn/112360724911005279

A foreground Apache exits, when you resize your terminal window. By design.

@b0rk the fun of trying to exit telnet or minicom etc... ctrl+[ is not intuitive...

Other fun one is running stuff in screen or nested screen. And different layers catching different bits.

Oh. And what happens when you hit ctrl+s...

@quixoticgeek @b0rk I've seen unfamiliar users caught out by an accidental Ctrl-z, if that counts?
@quixoticgeek @b0rk Even worse: ctrl+[ isn’t possible on a number of non-English keyboard layouts as [ requires modifier keys.
@b0rk running a thing that generates a lot of output (cat of a large file for example) in a slow ssh connexion. Control+C will work, but the program has already queued a lot of things to send before it will actually give you your prompt back, so it can take a long time to download and display all that output

@b0rk

Ending up with screen-inside-screen and having to figure out how to detach the inner one.

Having a program leave the terminal in some weird state when killed (either without echo, or in that weird alternate charset mode that can be fixed by _outputting_ ^O).

Not having job control at all (i.e. can't kill or suspend anything that I start in foreground) in some kinds of emergency shells (probably due to something like http://lists.busybox.net/pipermail/busybox/2002-June/006397.html).

Problems with terminals that are misconfigured so that control sequences are misinterpreted (most recently I had the issue when sshing to something that didn't understand `TERM=rxvt-unicode`).

[BusyBox] re: CTRL-C over serial console

@b0rk I learned in one off your other threads about a way to “detach” a process after putting it to the background, so that closing the window does not kill it, but I forgot the term (which means I didn’t really learn.) it was counterintuitive, as it often is. Something like orphanise or some crap.
@oscherler nohup or disown maybe?
disown isn't POSIX but it's often used in bash and ksh
@b0rk Hung NFS mounts on some systems (Solaris at least thru 10, older Linux) will get anything looking at them hung hard enough to not respond to ^c or anything else, even a KILL signal from other programs. So anything like df or ls is a black hole.