fish_postexec and fish_prompt don't emit when command is aborted (e.g. with ctrl-c)

[faho]

As mentioned in #2139, try the following:

function postexec --on-event fish_postexec
    echo postexec
end
function prompt --on-event fish_prompt
    echo prompt
end
sleep 5 # Press ctrl-c to abort

Neither event will fire. When the sleep runs to completion both will.

This completely precludes a fishscript solution to #2139 because every command could disable the keypad again (i.e. be equivalent to tput rmkx; sleep 5)

[pickfire]

I tried that and it seems that it is always printing something:

Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
prompt
[I] ivan@alarmpi ~> ls
c/  Desktop/  Downloads/  links.txt  MagPi37.pdf  pri/  TODO  wg/
postexec
prompt
[I] ivan@alarmpi ~>
postexec
prompt
[I] ivan@alarmpi ~>

[faho]

The important thing is that you don't let the command finish but abort it by pressing "ctrl-c" - try it with sleep 5.

[pickfire]

Can show show me how to do it? Maybe you could try adding it to a fish-shell branch to test it.

[faho]

Like I wrote above - just add those functions, run sleep 50000 (the number doesn't matter, just that it's long-running enough to react), and press "CTRL" and "c" simultaneously. You should then not get either event, which you can see because there's no "postexec" or "prompt" in the output.

Edit: This is with fish master 32a3e15 - i.e. all the latest C++ code.

[pickfire]

Yeah, it is true. After I press ^c, it doesn't print anything, and there is exit code 130.

[sassanh]

Is there any workaround for it till next major version comes out?

[krader1961]

Is there any workaround

None that I'm aware of. Patches are welcome 😄

[floam]

Is there any workaround for it till next major version comes out?

It's not yet fixed in master, so there is not a real guarantee that it will be fixed in the next major. (Though that is what we strive for with that milestone set). Like @krader1961 says: Patches welcome 😄

[sassanh]

I'd love to work on this, but I guess it's not that simple for someone not familiar to the codebase. Could you please show me where's the related code? I'll see if I can manage my time to work on it.

[krader1961]

@sassanh It would be great if you fixed this but my suggestion that you attempt to do was tongue in cheek. That is, I didn't mean for you to take it seriously. Primarily because the code involved in this issue is very complex and hard to understand. But if you really want to make an attempt at fixing this start with the read_i() function in src/reader.cpp. Look at the statements that call event_fire_generic(). You then need to investigate how the interrupt_handler() function in src/input.cpp interacts with that code.

[floam]

Of course, a workaround for whatever it was you were trying to achieve with the actual function bindings might be possible... depending on what it was you were trying to achieve.