Earlier quoted context omitted.
Different programs may take different amounts of time to cleanup and close. To know if a signal failed takes human judgment or heuristic. A program receiving a signal is even able to show a confirmation dialog for the user to save stuff, etc. before closing.
That's a valid point. Another example is SIGHUP, which will cause some programs to exit but other programs to reload their config file. In certain very specific cases, that could even cause harm. So really what "kill" would be doing is automating a common procedure, which is different than taking responsibility for doing it correctly. It would need to be configurable. I still think it would be a net benefit since rig…
It's not common. If `kill` on its own (which does just SIGTERM) doesn't work, you're already in "something wrong is happening" territory, which is why:
>>> Given that this is the right way, it shouldn't be more tedious than the wrong way!
is also the wrong way to think about this. Trying a sequence of signals is not so much "the right way" as it is "the best way to handle a wrong situation". The right way is just `kill` on it's own. SIGTERM should always suffice. If it doesn't to the user's satisfaction for a nonjustifiable reason, then you can just `kill -9`, but this should be rare.
Trying a sequence of SIGINT, SIGHUP, and SIGABRT is technically better than SIGKILL but not really important unless you also want to write a bug report about the program's signal handling or fix it yourself. About SIGINT and SIGHUP, if SIGTERM doesn't work, it's unlikely that SIGINT or SIGHUP would. Likely, it would only be through oversight and the execution of default handlers.
`kill -9` is just like `rm -rf`. I wouldn't suggest that `rm` automatically run with `-r` or `-f` when `rm` on its own didn't work, and I wouldn't call automatically trying those flags "the right way".