Chris's Wiki :: blog/unix/JobControlHasDarkCorners
Recently I learned that the common Linux version of vipw does some odd things with your terminal's foreground process group, one of the cores of Unix job control, due to a change made in late 2019 (via). It does this to fix a problem that's described in the issue and sort of in the commit, but neither the issue nor the commit discuss the larger context of why all of this is needed. Also, the fix has a small omission which can cause problems in some circumstances. So how did we get here?
Vipw's job is to let you safely edit /etc/passwd (or with the right option /etc/shadow), but it's not an editor itself, it's a front-end on some arbitrary editor of your preference. It works by setting things up and then running the editor of your choice. This creates three different potential interactions with job control and the terminal. First, infrequently vipw will be running an editor that doesn't take over the terminal or otherwise do anything with job control (perhaps someone likes ed). When you type Ctrl-Z, the terminal sends the entire foreground process group SIGTSTP and everything stops. Second, ideally vipw will be running an editor that takes over the terminal and handles Ctrl-Z itself, but the editor carefully sends SIGSTOP (or SIGTSTP) to the entire foreground process group. Third, it may be running an editor that takes over the terminal, handles Ctrl-Z itself, but only SIGSTOPs the editor itself, not the entire process group.
This third case is the initial problem. If vipw does nothing about it and you type Ctrl-Z to such an editor, your vipw session will appear to hang until you type Ctrl-Z a second time. The editor has stopped itself, but vipw is only waiting for it to finish and exit, so from the shell's perspective it seems that vipw is still the active foreground program. Your second Ctrl-Z will suspend vipw, now that the editor is no longer trapping Ctrl-Z.
