Unix makes it trivial to write a wrapper script around `kill` that does exactly what you want -- that's the entire point.
No, it is exactly the point.
Unix gives you Lego pieces to build things from.
A bunch of small Lego pieces you can join however you like is way more useful than a giant chunk of Lego that someone has glued together into whatever lump they happened to need that day.
When you ask why your Lego bucket didn't ship with pieces preglued into exactly the combination you want today, people absolutely will reply saying you have all the pieces you need and you can just join them yourself.
Because that is the entire point of Lego.
If that wasn't what you wanted, perhaps consider a different kind of toy?
That way, everybody wins. Both those who don't like Lego playing (me) and those who do (you).
> If that wasn't what you wanted, perhaps consider a different kind of toy?
I'd switch from GNU/Linux to something with a more sane design in a heartbeat! Unfortunately for me, the only free operating system began life as a Unix-clone. Thanks to an historical artifact more than a testament to the greatness of the "Unix philosophy".
Fortunately for me, there are a lot of people who have understood that thinking of an operating system as a jumbled bag of Lego bricks doesn't lead to good system design and are doing something about it (systemd and many more projects).
By the way, I haven't down-voted you, but I think I understand why others did. Before calling stupid a pillar of a (programming) philosophy with decades of useful outcomes, you should stop and ask yourself whether it's just a matter of taste on your side or, even more likely, of ignorance.
If you've taken the time to understand why generations of professional have done that way, and if you you have something else to propose, than the discussion is welcome and the result will be interesting in every case.
Otherwise, it's just a waste of time.
Most people on HN are developers and not as fluent as system engineers in shells and UNIX tools. The need for minimalist, "silent" UIs comes with fluency. This is also true for network engineers and database administrators.
No, it comes from wanting to reuse the tool!
Would you like your browser to open plenty of pop-ups with messages like "Congratulations! The font XYZ was successfully loaded from C:\foo\bar" or "That's incredible! I looked for a JPEG on server www.qqq.com ... and it was there!"? No, you wouldn't. And I wouldn't like "mv" to babble every time it renames a file on the hard disk.
So what? Is desktop computing all that matters? Networking, scientific computing, mobile telephone, don't they matter?
Unix was never meant for looking magic to clueless users; it was meant for programmers, i.e. for people who use the computer and not just some programs written by other people. And, in its realm, it has been brilliant! Not perfect, but very good!
By the way, here's a link to learn something more: https://blogs.msdn.microsoft.com/wsl/
I.e. your "decades of useful outcomes" argument doesn't favor the point you are making because the opposite philosophy (a more verbose userland) has many times more "useful outcomes". Therefore, according to your own logic (which I don't subscribe to because I think popularity is a useless measure of sound design) you "should stop and ask yourself whether it's just a matter of taste on your side or, even more likely, of ignorance."
... except that they could and did. People were not lacking in imagination. A science fiction writer imagined the Internet-connected smart 'phone in 1976, and put it into a science fiction novel (calling it the "mini-sec") titled Imperial Earth. A decade before that, an engineer imagined windows, hypertext, the mouse, word processing, graphics, and video conferencing, and gave what was later called The Mother of All Demos in an ACM/IEEE conference in 1968.
It wouldn't make sense:
1) the TERM signal can be trapped by the process, and "kill" has no right to assume that the process is supposed to quit;
2) the KILL signal is managed by the kernel and it just works (if it doesn't, then your kernel is buggy and you have more serious problems); even if "ps" shows the process as still alive after a "kill -9", you can assume it'd dead process walking.
I think this is the source of the problem. kill really is just for sending signals.
In the "Unix philosophy" there's no standard way to end processes, normally you send it SIGTERM and hope that it catches that, cleans up and exits. If it doesn't it could be a bug in the program, or maybe the program uses SIGTERM with slightly different semantics (eg Celery will wait for its children's tasks to finish, and does the "normal thing" of exiting as fast as possible when it gets two SIGTERMS); in any case I think the idea is that it's a weird, non-standard situation and the user needs to explicitly send SIGKILL (kill -9), since doing so might be dangerous.
This is the essence of 'small, single purpose programs that work well with each other' rule.
Interestingly, it would only take the addition of a pdopen() to something like FreeBSD's pdkill() to get enough for a tool that opened a process descriptor, sent a signal to the process, and determined (with poll() and pdwait4()) whether the process then exited; with the open-descriptor-style interface guaranteeing that it was always referencing the same process.
I suspect the reason is that for most signals, kill can't determine if the signal was acted upon or not. But for KILL and TERM it could wait a few milliseconds and then print if the process is still alive or not.
Edit: those who are saying that I can write a wrapper script is missing the point. The point of computers is to be useful to their users, not to follow some philosophy people invented almost 50 years ago. Like if someone is bothered by kill showing messages, they can write a wrapper script (kill > /dev/null how hard is that?) or beg the developers to add a -q option to kill (like grep has) or write a new tool for sending signals.
Also, the program is called KILL so one could be forgiven for assuming it's main purpose is to KILL things...