Oh dear, this is the kind of slapstick that’s so painfully cringe it’s just sad.
I was a bit surprised by the early history: my guess would have been that killing a negative PID was introduced with the rest of the process group / job control features in BSD in the early 1980s. So I had a look in the CSRG archives:
Yeah the historical question still interests me. Did V9 really originate negative pid killing via /bin/kill, or did System V or SunOS already have it? If the main use case was shell job control, maybe there wasn't yet a good reason to expose it. The extent of my spelunking for the post was TUHS, the unix-history-repo, and playing around with kill on old unixes in the browser via v86.
I thought this was a great article. I appreciate the length they went to digging into the topic and contextualized it with historical facts. Like I didn’t know process groups were a thing and have been a thing since 1986. So much more to learn about.
The article does not say that procps' kill suffers from quality issues, but this seems to be one of the implicit take-aways. It is not too hard to add unit tests to exercise the various cases, and this would have found the issues and avoided the regressions. What are the tests like? Why weren't thorough tests added on the first command-line-parsing bug in 2013?
Yeah, to be honest this is the first time I have heard of negative PIDs for process groups, but I would have added a double dash in front of the argument as a matter of course. First learned that trick trying to delete a filename starting with a hyphen, back in the closing years of the last millennium.
Ultimately my takeaway is that the standard interface to kill is way too ambiguous for its own good. There is already a -s/--signal option for specifying the signal explicitly (rather than eg -9), perhaps it’s time that there was an explicit option to specify a process group too? It seems insane to overload everything into negative numbers as is currently done.
I think there's a lot of this in the older parts of UNIX heritage. Things that optimize for brevity far more than would appear sensible today. (creat? really? you couldn't spare the extra letter?).
I think it's part an aesthetic ideal that's kind of outmoded today and part the result of genuine technical circumstances at the time. If you're on a small video terminal or (god help you) an actual teletypewriter, every extra character echoed back at you is quite costly.
Oh gods the reference to Burn After Reading. The only part of that whole movie worth remembering.
That said, this mostly seems like bugs around using getopt() properly. getopt() style command line parsing has always seemed like a cure that's far worse than the disease.
fanf | 19 hours ago
Oh dear, this is the kind of slapstick that’s so painfully cringe it’s just sad.
I was a bit surprised by the early history: my guess would have been that killing a negative PID was introduced with the rest of the process group / job control features in BSD in the early 1980s. So I had a look in the CSRG archives:
userland kill(1) gained support in 1986 (same year as mentioned in the article) with a terse note that the kernel already supported it https://svnweb.freebsd.org/csrg/bin/kill/kill.c?r1=22692&r2=27200
the kernel code was provided by Sun the previous year https://svnweb.freebsd.org/csrg?view=revision&revision=18336
the man page (also 1985) says the feature was added for compatibility with System V https://svnweb.freebsd.org/csrg/lib/libc/sys/kill.2?r1=20034&r2=20999
I don’t know of an archive of System V source code from the 1980s so that’s as far as I’ll look.
[OP] acg | 18 hours ago
Yeah the historical question still interests me. Did V9 really originate negative pid killing via
/bin/kill, or did System V or SunOS already have it? If the main use case was shell job control, maybe there wasn't yet a good reason to expose it. The extent of my spelunking for the post was TUHS, the unix-history-repo, and playing around withkillon old unixes in the browser via v86.doctor_eval | 11 hours ago
that v86 link is so cool, I have not seen that before
fanf | 18 hours ago
wonk | 13 hours ago
I thought this was a great article. I appreciate the length they went to digging into the topic and contextualized it with historical facts. Like I didn’t know process groups were a thing and have been a thing since 1986. So much more to learn about.
Thanks for sharing.
gasche | 7 hours ago
The article does not say that procps' kill suffers from quality issues, but this seems to be one of the implicit take-aways. It is not too hard to add unit tests to exercise the various cases, and this would have found the issues and avoided the regressions. What are the tests like? Why weren't thorough tests added on the first command-line-parsing bug in 2013?
gcupc | 4 hours ago
I didn't immediately know what the problem was after seeing this bug, but I immediately guessed the solution:
I guess my brain is just so GNU poisoned that negative number args always have me reaching for --.
pm | 33 minutes ago
I lost interest as soon as I saw that. How is that a bug? That is the expected and documented behaviour.
gerikson | 4 hours ago
Yeah, to be honest this is the first time I have heard of negative PIDs for process groups, but I would have added a double dash in front of the argument as a matter of course. First learned that trick trying to delete a filename starting with a hyphen, back in the closing years of the last millennium.
xx | 8 hours ago
The text on this page is super large for me (on a 2560x1440 monitor) and surprisingly, zooming out doesn't help at all!
It seems the culprit is this CSS rule:
Disabling this rule makes the text a sane size.
Otherwise, great article!
neilmadden | 2 hours ago
Ultimately my takeaway is that the standard interface to
killis way too ambiguous for its own good. There is already a-s/--signaloption for specifying the signal explicitly (rather than eg-9), perhaps it’s time that there was an explicit option to specify a process group too? It seems insane to overload everything into negative numbers as is currently done.muvlon | 2 hours ago
I think there's a lot of this in the older parts of UNIX heritage. Things that optimize for brevity far more than would appear sensible today. (
creat? really? you couldn't spare the extra letter?).I think it's part an aesthetic ideal that's kind of outmoded today and part the result of genuine technical circumstances at the time. If you're on a small video terminal or (god help you) an actual teletypewriter, every extra character echoed back at you is quite costly.
icefox | 3 hours ago
Oh gods the reference to Burn After Reading. The only part of that whole movie worth remembering.
That said, this mostly seems like bugs around using
getopt()properly.getopt()style command line parsing has always seemed like a cure that's far worse than the disease.bdesham | an hour ago
I doubt they would have had so many problems if they had used Python’s
argparsemodule. Unfortunately,,majaha | 3 hours ago
uutils haters in shambles