$status incorrect when SIGSTOP is sent

[andyearnshaw]

I'm noticing a discrepancy when backgrounding in Fish shell. In fish, zsh and bash, do the following:

1. Run sleep 10000000
2. Press Ctrl + Z
3. Run echo $? for bash/zsh, echo $status for fish

In zsh and bash, I get 146. In fish, I get 1, or 0 if I send kill -stop with the pid of the sleep process.

[faho]

My bash (4.3.42) and zsh (5.1.1) give me 148, not 146.

Also: What would you like to do? If you'd like to detect when something has been backgrounded, this isn't actually a proper way to do it, because any program can return 148 or 146 (in fact they can return anything from 0 to 255). So we should find a better way.

[andyearnshaw]

Many status lines (including mine) have an error indicator by checking the status of the last command. I slightly modified mine in my bash/zsh scripts to ignore 146, because I background a lot and don't want it to be considered as an error. It works for my main system where I use this prompt, and that's good enough for me at the minute.

The reason you get 148 and I get 146 is because SIGSTP/SIGSTOP numbers aren't portable (I'm running fish on Mac OS X). I don't think they can return anything from 0 to 255 in bash and zsh, though, as the ABS guide specifies that exit codes 128+n are reserved for signals (where n is the signal code), and zsh seems to follow suit there, so maybe fish should too. I haven't tried all other signals, but SIGKILL – whose code, 9, is – seems to give the correct result (137) in fish.

I'm all for detecting that the process was backgrounded, as it does seem like a better approach if it's portable. However, I think it's probably a good idea to fix this too.

[faho]

I don't think they can return anything from 0 to 255 in bash and zsh, though, as the ABS guide specifies that exit codes 128+n are reserved for signals (where n is the signal code), and zsh seems to follow suit there, so maybe fish should too.

That's a convention, not something that's technically enforced - compile and execute this C code, then check the return code:

int main() {
  return 255;
}

My bash also gives 255.

I slightly modified mine in my bash/zsh scripts to ignore 146, because I background a lot and don't want it to be considered as an error.

Okay, so you'd like to not show it in the prompt. So... what should this look like? My first thought was to make a signal handler for SIGSTOP/SIGCONT that sets a "job_exited" variable or similar, and then add that to the prompt, but that doesn't work currently since fish doesn't seem to catch it (I know that it's possible on linux at least since it was part of one of the worst design decisions of upstart).

I don't have any idea for a particularly beautiful interface - though I do like correct interfaces.

[andyearnshaw]

That's a convention, not something that's technically enforced

Of course, but I'm talking about something of personal preference. I'd rather have to use the traditional method of finding out if the last command was successful for the odd program that breaks convention than see an error every time I stop vim to do something on the command line.

Okay, so you'd like to not show it in the prompt. So... what should this look like? My first thought was to make a signal handler for SIGSTOP/SIGCONT that sets a "job_exited" variable or similar, and then add that to the prompt, but that doesn't work currently since fish doesn't seem to catch it (I know that it's possible on linux at least since it was part of one of the worst design decisions of upstart).

Doesn't function --on-signal only work for signals sent to fish (as opposed to the subprocess)? Or were you thinking of something else?

Perhaps something to that effect could work:

function my_sig_handler --on-background
    set __last_process_stopped 1
end

Or maybe even a new fish function that would kill 2 birds with one stone:

function fish_background_message
    ...
end

function fish_foreground_message
    ...
end

Would allow me to customise (or silence) the messages printed to the console on fg/bg, something that's been on my wishlist since I started playing around with fish a few weeks ago.

[faho]

Andy Earnshaw notifications@github.com writes:

Doesn't function --on-signal only work for signals sent to fish (as opposed to the subprocess)? Or were you thinking of something else?

Humm, I was under the impression that fish receives the signal. Guess
I'll have to read up on how this exactly works.

Perhaps something to that effect could work:

function my_sig_handler --on-background
    set __last_process_stopped 1
end

Yeah, that might be okay - or rather a special event "fish_background"
or so, so we don't have to have another option.

Or maybe even a new fish function that would kill 2 birds with one stone:

function fish_background_message
    ...
end

function fish_foreground_message
    ...
end

Would allow me to customise (or silence) the messages printed to the console on fg/bg, something that's been on my wishlist since I started playing around with fish a few weeks ago.

Yeah, but this wouldn't solve the original problem - we'd usually want
to reset $status for such functions.

---

Reply to this email directly or view it on GitHub:
#2524 (comment)

[zanchey]

Seems like a sensible thing to do.

[faho]

The "job has stopped" message is now customizable via fish_job_summary, so I think this has been done for some time.