For a small suggested wording mod to killall.1, what's your preference: Describe change in a ticket, or upload as a doc patch? Either is fine with me, just asking so I do it the way you want the first time. Thx.
Patches are fine. A small description of what the problem is or what is fix does helps too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2013-10-02
OK, will do. All the patch does is specify that -r expects a POSIX ERE, and lists regex(3) in the "SEE ALSO" section. I'll provide a short description along with the patch explaning why that change is beneficial to readers.
Btw, while I was looking over the man page, I also noticed that the SYNOPSIS does not seem to indicate the presence of the 'signal' parameter when it is specified in bare form, i.e. as simply -n or -NAME.
For example, this form
$ killall -s HUP
does conform with the SYNOPSIS, because the SYNOPSIS contains
[ -s , --signal signal ]
which describes "-s HUP". But the 'bare' form
$ killall -HUP myprocess
technically does not conform with the SYNOPSIS, because there is no operand listed in the SYNOPSIS which corresponds to "-NAME" or "-n".
If you agree that this is a shortcoming, I'll be happy to fix it as well while I'm in there. Just let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please do not do this as this feature of using the SIGNAL names as option is in common use. That is do NOT break existing scripts of the users thereout without need.
Btw: the manual page of the standard command kill(1) does describe this feature:
-s, --signal=SIGNAL, -SIGNAL
specify the name or number of the signal to be sent
... IMHO you may fix the manual page of killall(1)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the noise ... I've overseen that not the C code will be affected but the nroff text ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2013-10-04
Can a moderator please approve earlier Anonymous post (02-Oct, 23:15 UTC) so we can see it? It still shows only as "post awaiting moderation" as of 04-October, 15:45 UTC. Thx.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Patches are fine. A small description of what the problem is or what is fix does helps too.
OK, will do. All the patch does is specify that -r expects a POSIX ERE, and lists regex(3) in the "SEE ALSO" section. I'll provide a short description along with the patch explaning why that change is beneficial to readers.
Btw, while I was looking over the man page, I also noticed that the SYNOPSIS does not seem to indicate the presence of the 'signal' parameter when it is specified in bare form, i.e. as simply -n or -NAME.
For example, this form
does conform with the SYNOPSIS, because the SYNOPSIS contains
which describes "-s HUP". But the 'bare' form
technically does not conform with the SYNOPSIS, because there is no operand listed in the SYNOPSIS which corresponds to "-NAME" or "-n".
If you agree that this is a shortcoming, I'll be happy to fix it as well while I'm in there. Just let me know.
Please do not do this as this feature of using the SIGNAL names as option is in common use. That is do NOT break existing scripts of the users thereout without need.
Btw: the manual page of the standard command kill(1) does describe this feature:
... IMHO you may fix the manual page of killall(1)
Sorry for the noise ... I've overseen that not the C code will be affected but the nroff text ;)
Can a moderator please approve earlier Anonymous post (02-Oct, 23:15 UTC) so we can see it? It still shows only as "post awaiting moderation" as of 04-October, 15:45 UTC. Thx.
Done!
I thought it had been released, but obviously not. Now all we need is the patch, huh?
First we need a response to the prior post, which is why I had asked that that it be approved and made visible:
So: All we need first is a response to the above, huh? :)
Yes for POSIX reference and Yes for Synopsis change.
Patchfile attached.
This was applied in commit [9c03e5]
Related
Commit: [9c03e5]