Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
faho opened this issue Sep 3, 2015 · 12 comments
Labels
bug Something that's not working as intended
Milestone

Comments

@faho
Copy link
Member

faho commented Sep 3, 2015

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
Copy link
Contributor

pickfire commented Sep 3, 2015

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
Copy link
Member Author

faho commented Sep 3, 2015

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
Copy link
Contributor

pickfire commented Sep 3, 2015

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

@faho
Copy link
Member Author

faho commented Sep 3, 2015

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
Copy link
Contributor

pickfire commented Sep 4, 2015

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

@zanchey zanchey added the bug Something that's not working as intended label Sep 4, 2015
@floam floam added this to the next-major milestone Jul 5, 2016
@faho faho changed the title fish_postexec and fish_prompt don't emit when command is aborted fish_postexec and fish_prompt don't emit when command is aborted (e.g. with ctrl-c) Jul 28, 2016
@sassanh
Copy link

sassanh commented Jul 29, 2016

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

@krader1961
Copy link
Contributor

Is there any workaround

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

@floam
Copy link
Member

floam commented Jul 30, 2016

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
Copy link

sassanh commented Jul 30, 2016

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
Copy link
Contributor

krader1961 commented Jul 30, 2016

@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
Copy link
Member

floam commented Jul 30, 2016

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.

@sassanh
Copy link

sassanh commented Jul 30, 2016

OK, I just thought when 2 core developers say patches are welcome they're too busy to take care of it themselves 😆

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something that's not working as intended
Projects
None yet
Development

No branches or pull requests

6 participants