What I was missing: these users have complicated code in their $PS1 or other 'prompt variables', which makes the shell do things every time they change directories.
Indeed, the the title contains the word 'prompt'.
This is apparently a solution for a problem I don't have. (There's no way I'd ever tolerate a slow cd command, async or not!)
The CLI works like this: I type in a command, I get to see the result (if any) and back to step one.
If doing a `cd` command takes 3 seconds, I'll have to wait for it to be ready to run the next command anyways, because my `rm` command has to run in there or I might have a problem.
For hasty typers like myself this could pretty easily backfire.
By the way, you can type the next command as the previous is running. You might get gibberish on screen, but you're sure it's only executed after the former is done.
Or you could just type several commands like `./configure && make` so that you can switch to something else in between.
In any case I don't see any advantages of an async prompt, just potential dangers.
My understanding is that the cd command finishes before the next prompt gets displayed; the command that continues running in the background is `git status` inside the new working directory.
More specifically put, this is a solution to a problem you don't have. Some people want their prompt to display more ancillary information about their environment. Those people want a quick, responsive prompt as much as you, and one of the strategies for having both processing this extra display info and having a fast prompt is async.
I think the CWD is actually changed before the PS1 magic queries for the status of the version control system--meaning that your `rm` would hit the correct target.
But, I'm guessing--I haven't used a fancy prompt like this.
Either way, it doesn't make much sense to me. For example, if `cd` fails you need to go back a few steps, etc.
This uses zsh-async: https://github.com/mafredri/zsh-async
It would be slightly more complex... for that matter, I tend to like multi-line prompts anyway, I don't like the line I'm typing on to wrap until there's a lot there, so prefer more details to be printed before the actual prompt.
ls | netcat 127.0.0.1 5555
while :; do netcat -l 5555; done
echo 'ls' > pipe
With this script I can have the following layout:
| | |
| Vim | output |
| | |
| | |
:update | RunFifo bash %
A lot of themes don't use vcs_info to get this information, and consequently take time. I'm not sure what other types of information you would want to show that would take a long time to load.
Mosh is for local echo of what you type when you have intermittent connectivity, whereas this lets you lazily calculate variables that might be included in your prompt (like "git status" on a large repository).
What i'd like instead, is based on the same issue/idea, which would be a real "linemode" where your prompt is "locally updated" and anything sent to "the shell" is asynchronous.
This would not fork processes in the background (i want to be able to be selective on that obviously! so it would queue up processes if i dont specify '&' for example) but ensure that you can always get back to the prompt.
This also makes it so that the prompt would be instant over the network as well.
Note that some protocols do support linemode, just not SSH, or obviously not the native common shells either, at least, not without building a forked version