sigstatus segment breaks with procps-ng kill about fishline

[0rax]

Seems like trying to be POSIX is not always the solution (well fish itself is not POSIX so hey, so I wont complain here).

Will try to see how to fix that before releasing fishline v3. In the same time you may want to fall back to the simple status segment then)

For your link I am not sure this solution would be also compatible with OSX / BSD derivative, I will pop up a Ubuntu 16.04 VM in order to check this out.

Thanks for your report !

[kanbara]

Awesome. Just a note-- it also happens in bash/dash with the procps-ng `kill' at least on Ubuntu 16.04 when using the non-builtin, as the issue is with the actual implementation of the list function. I'll try to raise it with the procps-ng maintainers too, just to see if they have a good reason for not identifying the signals or using shorthand (e.g. --list= works but not -l )

[0rax]

Just tested some stuff, all kill implementation that I was able to test (latest Ubuntu [procps-ng], latest Debian [procps-ng], latest alpine [busybox kill] and OSX [BSD kill & GNU gkill]).

It seems like using a simple math $status - 128 to retrieve original signal code works perfectly as an argument to all of those operation (kill -l kill --list=(math $status - 128)). So we have a solution for that.

The blocking factor is that kill -l $sigcode does not work on procps-ng while kill -l$sigcode or kill --list=$sigcode works only on procps-ng. I may be able to add a fix in the init.fish script in order to check what kill version is availlable in order to choose the right on in the sigstatus segment as only the procps-ng version expose a -V option to check its version.

Something like

kill -V ^/dev/null | grep "procps-ng"; and set FLINT_NGKILL true

Another solution, that might be cleaner is to generate the list of signal code just based on kill -l as querry them via their index. The thing is I dont know how multi platform this solution would be, but from what I have tested /bin/kill -l| tr ' [a-z]' '\n[A-Z]' will always generate an ordered list os signal from 1 to 31.

Will try to take a closer look at it but yeah, the fact that kill -l $sigcode with a space does not work is a bummer.

[0rax]

Just pushed a fix to branch bugfix/sigstatus (dev...bugfix/sigstatus). If you wish to test this, I will do my best to test that with other kill implementation in the same time.

Just be aware that this is based on fishline v3 dev branch so if you are currently running fishline v2 just be aware that you will need to update the way you initiliaze it (see release v3.0.0-beta.1).

Edit: miss clicked the close issue ...

[kanbara]

I'll certainly take a look at the fix tomorrow when I'm at my work machine.

I'm gonna open an issue with procps-ng kill to see if they can do a shorthand argument form for kill -l $sigcode. Won't matter too much to solve the issue now, but would allow to make it simpler in the future. I bet they have some reason for not emulating kill, but who knows.

[0rax]

Yes, I dont really know why that wouldn't be compatible with pretty much all other implementations on this specific issue.

In a way this fix should perform better than the old implementation (as it does only call kill once for the whole session) but we never know. Keep me informed when you had time to test this !

[kanbara]

I just tested with procps-ng kill and it appears to work well. Sent some signals to a process and also did things with process num > 128 (e.g. -C) and it all looks good to me.

[0rax]

Thank you very much for this, I just updated the segment to use $status - 128 to querry the signal instead of just $status so yeah, glad it works now !

FYI, the fix will be merged soon and availlable in the next beta release (fishline v3.0.0-beta.2) which is scheduled for this week.