Executing fg via binding makes keybindings not work the second time

[jonhoo]

With this binding in config.fish:

function fish_user_key_bindings
    bind \cr 'fg >/dev/null ^/dev/null'
end

Do the following commands in a new shell:

$ vim
# <press Ctrl+Z inside vim to send to background>
# <press Ctrl+r, vim (correctly) restored>
# <press Ctrl+Z again>
# <press Ctrl+r, ^R is printed to terminal, vim is not restored>

In particular, no key bindings work at this point until enter or ^J is pressed.

[faho]

I can reproduce this.

Some more info:

• It's not just \cr, it appears to be binding fg that's causing the issue
• It's not just vim, less also works
• Running fg manually works
• It's also an issue if you don't bg again but quit
• Syntax highlighting and suggestion are also non-functional, only entering basic text seems to work
• Entering commands works, but echos them again on the next line, highlighted

In other words:

$ touch halibut
$ less halibut
<\cz>
<\cr>
<q>
$ echo barracuda # in white
echo barracuda
barracuda # dundundundundundundundundun dun dun

[jonhoo]

I get almost the same behavior as @faho on 97edc96, except that the scary "dundundundundundundundundun dun dun" part seems to be missing.

[faho]

the scary "dundundundundundundundundun dun dun" part

HAhAHAHAhA.... that was my attempt at a reference... 😆

[jonhoo]

Hehe, yes, I got that 😉

[jonhoo]

This is really unfortunate, as I run into this multiple times a day.
@ridiculousfish: Any pointers as to where I might start looking to fix it?

[faho]

@jonhoo: It's possible fish isn't resetting the terminal mode correctly. For me with a ToT fish just executing a single command (like true) interactively helps.

[krader1961]

Simply pressing enter after suspending the command the second time fixes the fish input state. I'm confident this is not a tty mode problem. You don't even need to use a full-screen program like vim or less. Simply running sleep 9999 then doing the \cZ\cR\cZ dance will reproduce the problem.

Frankly, I'm not sure this should even be allowed. If you've already started typing another command then press \cR to magically foreground a job what do you expect to happen to the characters you've already entered? If we do want to support this the fix probably lies in having the code that responds to \cZ (or whatever the suspend key is) forcibly redraw the command line and otherwise ensure it is in a sane state.

@jonhoo, I'm curious why you created that binding? Why not just type fg? Which is not to imply the issue you identified shouldn't be fixed one way or another. It just seems like a rather odd binding.

[jonhoo]

@krader1961: I don't think there's something magical about \cR with regards to output. The same could be said for \cZ and then manually typing fg, no? I use this binding because it is faster than typing fg<Enter>, and I do it a lot.

[krader1961]

@jonhoo: You misunderstood me. I agree there is nothing magical about the specific key sequence you bind the fg command to. You could use an arbitrary sequence like bind \eforeground fg. My point is that trying to execute the fg command from a key binding seemed weird as it saves maybe 100 ms of typing. Yes, it should "just work" in keeping with the fish philosophy; or, at least be disallowed with an explicit error message if there is no reasonable way to make this work reliably.

[jonhoo]

@krader1961: Oh, sorry. Yes, I'd be fine with this being disallowed if you were in the middle of typing a command. However, it should work fine if you haven't yet typed anything. While you're right it doesn't save much time, it certainly interrupts the flow somewhat if I'm flicking back and forth between, say, vim and my terminal, typing in something based on the command I just ran. I could use multiple terminal tabs/windows, but anything involving tab is fairly slow, as it's far from home row.

[rbong]

I believe it should work if something is already typed in if at all possible. Imagine if you're looking at a man page or another reference and wish to switch to/from the manual; it could be very useful.

In addition, fg could be only part of a larger binding. It is certainly annoying and prone to error to type the binding and thent typing in fg and enter. It's yet more characters if you wish to, say, run a command after fg separated by a semicolon, or type a space before fg to not log the command. In addition, it clutters up the terminal after exiting from the command. I am trying to do all of these things, as anyone trying to make fg part of a larger command might need to do.

[krader1961]

@rbong, I'm afraid I don't understand any of the scenarios you describe. Let's start with the first one:

Imagine if you're looking at a man page or another reference and wish to switch to/from the manual;

If I've typed man some-comand and pressed [enter] so that I'm looking at that man page the man command is now the foreground process. Which means fish won't receive any key presses and won't run the magic fg binding. Or are you suggesting that while running man some-command you type [ctrl-Z] to suspend it then start typing some-command --opt1 --opt2 and before pressing [enter] want to be able to invoke the fg binding to bring the man command to the foreground?

If the latter wouldn't it be simpler to simply open another shell and run the man command in parallel? That's what I normally do. That is, I normally have one or two terminals that I use for looking at documentation or source code while I'm actually editing code or entering other commands in a different window. That's more simpler and more general than what you seem to be trying to do.

run a command after fg separated by a semicolon

Huh? Under what circumstances does it make sense to put a process in the background then type something like fg; new-command? Granted, that should "just work" but I've never seen anyone do so in real life or in documentation, blog articles, etc.

or type a space before fg to not log the command

Double huh? Entering a space before fg will only keep fg from being logged. It will have absolutely no effect on whether the command being foregrounded was logged.

[rbong]

Sorry for my confusing scenarios @krader1961

If the latter wouldn't it be simpler to simply open another shell and run the man command in parallel?

It is the latter scenario. I admittedly also open another window... however, I can see how someone would find this useful. On systems with smaller screens restricted to the terminal, the user is forced to use a multiplexer, as I have been many times.

With this scenario, I meant to illustrate that it is in fact useful to have just fg in a keybinding and to use that keybinding in the middle of writing a command.

Huh? Under what circumstances does it make sense to put a process in the background then type something like fg; new-command?

In this scenario where the user is going from and to some foreground process (a very good reason for binding fg to a keystroke), the user may need to clutter up the window with fg commands. A user will eventually run

<space>fg; clear

Or,

<space>clear; fg

Or, wrap clear and fg in a function. It's probably not a good idea to name a function only one or two letters, meaning it's still more than a few extra keystrokes.

Entering a space before fg will only keep fg from being logged

This is what I mean. fg will not be logged. If the user desires fg to be in a keybinding along with some other functionality, they probably wish to hide the command.

I am just illustrating that it's more than just one extra keystroke because of the extra shell management required to recieve the same result.

[krader1961]

This is what I mean. fg will not be logged.

Entering [space]fg might make sense in shells which log each command. But, FWIW, it's not a useful optimization in fish because fish will only ever have one instance of each unique fg command in the history file.

I've been programming since the days when 80 column IBM/Hollerith cards were still being used and a 80x24 CRT terminal was bleeding edge. Having two such terminals was considered a luxury. And yet I can't ever recall typing fg and bg so many times that it made me frustrated. But I'll agree that others may have different styles of working and/or concerns that makes binding fg to a key sequence a reasonable optimization for them. So I'm not arguing against making this work. I'm just perplexed that it's such a big deal.

[rbong]

@krader1961 It's not a big deal, just a slight nuisance. If my scenarios seem weird, it's because I am using remote key presses in tmux to suspend any foreground processes, do something, and then go back without worrying about what just happened. It's two keypresses if fg works in a keybinding, which is fast uninterruptable and clean, but otherwise I have to worry about the state of various other things in the shell like I mentioned. I think I failed to generalize my situation.

[bruce-hill]

This problem is caused by commit b67526a, which disabled the code that would otherwise restore the correct terminal mode after returning from a job. Reverting that change allows bind \cF fg to work correctly. From testing on linux, the cd .; ftp test case mentioned in the comment appears to work correctly even with the change reverted, so perhaps the root cause of the original bug (#121) was fixed by one of the many changes since 2012, but I don't have midnight commander, so I can't test the exact original repro steps.

*Edit: the original bug reappears if the change is rolled back. I don't know exactly how to make everything work, but it definitely has to do with the block of code in b67526a. A reliable test case for me is ls | sh -c 'read </dev/tty >/dev/tty && echo "You said: $REPLY"'

[bruce-hill]

I believe this patch fixes the issue without reintroducing the original bug #121:

1035c1035
< static bool terminal_return_from_job(job_t *j) {
---
> static bool terminal_return_from_job(job_t *j, int restore_attrs) {
1060,1072c1060,1070
< // Disabling this per
< // https://github.com/adityagodbole/fish-shell/commit/9d229cd18c3e5c25a8bd37e9ddd3b67ddc2d1b72 On
< // Linux, 'cd . ; ftp' prevents you from typing into the ftp prompt. See
< // https://github.com/fish-shell/fish-shell/issues/121
< #if 0
< // Restore the shell's terminal modes.
< if (tcsetattr(STDIN_FILENO, TCSADRAIN, &shell_modes) == -1) {
< if (errno == EIO) redirect_tty_output();
< debug(1, _(L"Could not return shell to foreground"));
< wperror(L"tcsetattr");
< return false;
< }
< #endif
---
>     // Need to restore the terminal's attributes or `bind \cF fg` will put the
>     // terminal into a broken state (until "enter" is pressed).
>     // See: https://github.com/fish-shell/fish-shell/issues/2114
>     if (restore_attrs) {
>         if (tcsetattr(STDIN_FILENO, TCSADRAIN, &shell_modes) == -1) {
>             if (errno == EIO) redirect_tty_output();
>             debug(1, _(L"Could not return shell to foreground"));
>             wperror(L"tcsetattr");
>             return false;
>         }
>     }
1091c1089,1092
<             terminal_return_from_job(this);
---
>             // Only restore terminal attrs if we're continuing a job. See:
>             // https://github.com/fish-shell/fish-shell/issues/121
>             // https://github.com/fish-shell/fish-shell/issues/2114
>             terminal_return_from_job(this, send_sigcont);

[zanchey]

@ridiculousfish @faho @mqudsi would you be able to take a look at the comments and patch from @bruce-hill and see if this is something we should take for 3.1?

[ridiculousfish]

Tentatively pulling into 3.1 so we don't lose it.

[ridiculousfish]

This fix looks good and makes sense, fixed as 9fd9f70 . Thanks @bruce-hill !

[faho]

Reopening because the fix for #7770 reintroduces this