Bug#1025915: skill: -p $pid seems broken

[Craig Small]

On Thu, 5 Jan 2023 at 18:26, Chris Hofstaedtler  wrote:
> Right. For the avoidance of doubt, if you think removing it is a
> better option, from my PoV, please do so.
It would be nice, but we're sort-of locked in for the "user API".  I
would rationalise the ps command line parsing first.
If you're writing new scripts, then pkill is better maintained than
skill but in any case, a bug is a bug.

 - Craig

Bug#1025915: skill: -p $pid seems broken

[Chris Hofstaedtler]

Hi Craig,

* Craig Small :
>   Thanks for your bug report. skill is one of those programs that isn't
> used or loved much, but still hangs around. That being said, it shouldn't
> have bugs like this!

Right. For the avoidance of doubt, if you think removing it is a
better option, from my PoV, please do so.

Thanks for fixing the bug anyway!

Happy new year,
Chris

Bug#1025915: skill: -p $pid seems broken

[Craig Small]

Hi Chris,
  Thanks for your bug report. skill is one of those programs that isn't
used or loved much, but still hangs around. That being said, it shouldn't
have bugs like this!
When the program was converted to use the new API, the bit of code that
actually checks there is a match against the pidlist wasn't transferred.

It's a simple two-liner to fix and will be in the next Debian and upstream
release. There's also a test explicitly for this use-case.

 - Craig

Bug#1025915: skill: -p $pid seems broken

[Chris Hofstaedtler]

Package: procps
Version: 2:4.0.2-2

Dear Maintainer,

skill's -p flag seems to have stopped working as a selector.

In version 2:3.3.17-5, this did what I expected:

% echo $$
3004161
% skill -n -p $$
3004161

In 2:4.0.2-2 in unstable:

% echo $$
50078
% skill -n -p $$
[list of ALL pids, including 50078]

Looks like -p pid has become a "match any" selector. That seems
unlikely to be the intended effect.

I believe in 2:3.3.17-7.1 this also still worked fine.

Thank you for maintaining procps.

Best,
Chris