Timeline for Remember a half-typed command while I check something
Current License: CC BY-SA 2.5
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 19, 2023 at 13:26 | comment | added | Sebastian Carlos | Here's a variation of the Ctrl-Z solution, which should work for Bash. | |
| Apr 13, 2017 at 12:36 | history | edited | CommunityBot |
replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
|
|
| Jun 8, 2016 at 7:46 | comment | added | Gilles 'SO- stop being evil' |
@EliBarzilay Once again, that's the behavior I intended. If you prefer to recall the line automatically, then by all means include the call to get-line in your configuration.
|
|
| Jun 8, 2016 at 4:20 | comment | added | Eli Barzilay |
@Caleb, re (2) with that addition it only does the recall if you ^Z^Z while typing a new command, which fixes a weird thing that happens without it. Just it with your version: sleep 10 RET ^Z pwd (no enter) ^Z^Z -- at this point it will bg-es the sleep, but it leaves you with an empty line, and after another RET you get the restored line. Then try the same sequence with my addition.
|
|
| Jun 7, 2016 at 17:33 | comment | added | Gilles 'SO- stop being evil' | @EliBarzilay (2) That's intended behavior: backgrounding a job with ^Z^Z doesn't automatically recall a previously-suspended command line. (3) I think in this case there isn't, but I have the habit of including it in functions that might be used in interactive sessions with all kinds of “crazy” options for user preferences. | |
| Jun 7, 2016 at 17:17 | comment | added | Eli Barzilay |
@Caleb: two comments & a question: (1) very nice hack to bind this to ^Z and do a bg on an empty line! (2) it's a bit better to do a zle get-line before the zle redisplay --- this makes it work fine for cases like: ^Z to suspend something, start a command, ^Z^Z to bg the something and continue editing; (3) is there any need for the emulate -LR?
|
|
| May 2, 2013 at 9:50 | comment | added | Gilles 'SO- stop being evil' |
@Caleb push-input suspends the whole input buffer, whereas push-line suspends only the current line. If I'm typing a multiline command, I want to suspend the whole command, so push-input is the right one. I find push-input more often useful than push-line (if I want to delay a line in a multiline input buffer, I can simply navigate to the beginning of the line and insert a newline), so I in fact wonder why push-line got the default keybinding and not push-input.
|
|
| Apr 25, 2011 at 20:39 | comment | added | Gilles 'SO- stop being evil' |
@Caleb: No, it's just that I find the combination of the two both convenient (push-line is useless on an empty line, having bg on Ctrl+Z is only useful when I've just suspended that process with Ctrl+Z) and mnemonic (I'm either backgrounding the process or the partial command line).
|
|
| Apr 25, 2011 at 18:20 | comment | added | Caleb | As far as I can tell the only difference is the same-binding effect to background a running job. Am I missing something? | |
| Apr 25, 2011 at 18:17 | comment | added | Gilles 'SO- stop being evil' |
@Caleb: I don't know why I use push-input rather than push-line here, push-line does seem more appropriate (maybe old versions of zsh only had push-input?). But that's not a replacement for the rest of the function.
|
|
| Apr 25, 2011 at 17:42 | comment | added | Caleb |
your function is admirable, but did you know that zsh has a function for that built in already? It's called push-line and all you need to do is use bindkey to get to it.
|
|
| Apr 7, 2011 at 20:06 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 2.5 |