it doesn't, ctrl-z only suspends process and switches to backgroud - the thing is still alive try ctrl-z and then type bg command - you will see a list, you can resume with fg [number]

Ctrl-z by itself doesn't actually switch the process to run in the background, it stops the process. Running 'bg' is what starts the process back up running in the background, 'fg', like you said, resumes the process in the foreground and 'jobs' is the command you can run to see a list of processes that are running.

Since the question was "Ctrl-z works universally", I feel obliged to point out that ctrl-z sends SIGTSTP, which can be blocked--not to be confused with SIGSTOP, which cannot be blocked. I don't know of any program that does intercept SIGTSTP (except a test program I wrote that tries to print the name of any signal it receives), and I suspect that "polite" interception would be to release a few resources and then accept being paused--but, in theory, a program could ignore it.

Many curses programs (for example vim) intercept ^Z to set the terminal back into a more normal mode and then pause.

This is probably a stupid question, didn't know about bg and fg before. But after playing around with it, it feels pretty amazing, why even use screen/tmux when you have these?

Screen has aaugh easier interface for multitasking, including things like stderr not bleeding out from whatever background tasks you're running. Not to mention that switching back and forth between screens is what it's designed for and thus a lot easier than switching between job numbers. Also the ability to detach your screen and its running processes from being coupled to a specific login session, which is probably the main reason I started using screen instead of multiple terminals in the first place.

With bg, it is likely to suspend itself again by attempting to read from the terminal (which a text editor is likely to do basically all the time).

Well, it might still run but it lets you out of the editor, which is the goal here. You can just kill -9 it afterwards.

If you have good reflexes, you can type "^Z" right after "kill -9", before the syscall to send the signal is executed.

Legend has it that, if you do, you bring on the Singularity immediately.

There is no reason for -9 here - all the major unix editors happily exit on SIGTERM.

Not really. Some programs disable it including vim (at least on some setups).

Every vim I've ever played on has respected `ctrl-z`. In fact, I use `ctrl-z` to jump out of my vim (to restart a server, ls the local dir, etc).

My vimrc has

    source $VIMRUNTIME/mswin.vim
    behave mswin

which maps Ctrl-z to undo.

You monster.

Well I'll be damned. Never thought of trying it. Thank you.

this has got to be trolling. right? right?! i'm so confused.

Back when I first started my CompSci degree, a friend of mine always "quit" emacs with ctrl-z. Or, at least he did until he managed to fill his entire home directory quota with emacs backup files that were never cleaned up...

Ha, I still do that!

    $ jobs
    [4]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [5]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [6]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [7]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [8]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [9]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [10]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [11]   Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [12]-  Stopped                 emacsclient -a '' -nw [redacted]  (wd: [redacted])
    [13]+  Stopped                 emacsclient -a '' -nw [redacted]

But since they're all emacsclients it doesn't really matter.

Don't you frequently deal with:

  /private/tmp/foo.txt locked by jnpatel@mac... (pid 14836): (s, q, p, ?)?

because of the lock files?

Nope, because emacsclient ends up opening them all in the same process (that's the beauty/entire point): Fork off an emacs in the background:

  emacs --daemon

Then run emacsclient to connect to it (open a new buffer in the daemon and switch to it):

  emacsclient -nw some_file

When you "quit" (with C-x C-c), it really just quits that client, but the main emacs is left running.

This has a number of benefits: 1) no locks like you mention, 2) access to all open buffers (even unsaved) from every emacsclient that's currently running (since they're really all just opening buffers in a single instance), 3) blazing startup speed (emacs is already running, you're just connecting to it and splatting a new buffer to the terminal).

I still remember how happy I was when I found out about that. On all servers I use (at home and at work), starting an emacs daemon is usually among the first things I do after rebooting.

Do you know about the "--no-wait" option for emacsclient?

Yes. But it doesn't play well with "-nw".

Ah yes, good point. In that case, the solution is `C-x #` to finish an emacsclient session without causing the server to quit.

Luckily C-x C-c also does that now.

`fg` is your friend