
An Asynchronous Shell Prompt - gabamnml
http://www.anishathalye.com/2015/02/07/an-asynchronous-shell-prompt/
======
daveloyall
If you're like me, none of this made sense at first.

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!)

~~~
kolme
I'm apparently like you, none of this make sense to me.

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.

~~~
mtdewcmu
>> 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.

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.

------
jerf
You know, you could probably build a whole new shell around this whole
concept. Solve a couple of the fundamental UI issues (i.e., I don't really
want my insertion point or the text I'm editing to be bouncing around as
things chunk in) and I wouldn't be surprised you could take this concept
further than you might initially think. For instance, one issue I often find I
have is stale information as I flip around my shells; if my source plugin was
updating in realtime everywhere, that would be useful. And I mean that as just
one example of the sort of thing that could be useful if this was taken in
deep in a new shell.

~~~
zem
Ever since I first saw Mathematica, I've been amazed that the notebook model
hasn't caught on more generally. It would make this paradigm perfectly natural
- delayed information would clearly be loading in its own frame, and you would
expect the visual scroll and input focus to both be centred on the current
frame, so it wouldn't be odd to have to go backwards to look for an update.

------
micampe
Another example:
[https://github.com/sindresorhus/pure](https://github.com/sindresorhus/pure)

This uses zsh-async: [https://github.com/mafredri/zsh-
async](https://github.com/mafredri/zsh-async)

~~~
provemewrong
Wait, why is npm used for a zsh prompt installation? I thought it was
javascript/node.js package manager.

------
tracker1
It might be interesting to have the "prompt" and details at the bottom of the
screen... have your status details update async, and keep your prompt
relatively raw.. much like text-mode chat clients.

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.

------
jacobolus
One thing that would be nice would be to put the output of shell commands into
a separate column from the prompt, with an ability to collapse or expand the
output, outliner style. Modern computer displays have lots of extra real
estate, there’s no reason to require everything to fit into a window 60 or 80
characters wide.

~~~
jahnu
Using netcat you can get this

send:

    
    
      ls | netcat 127.0.0.1 5555
    

receive:

    
    
      while :; do netcat -l 5555; done
    

You could make it cleaner but that basic idea works

~~~
kolme
I do something similar but with named pipes. I use it to dispatch commands
from vim to another tmux pane (or screen, for that matter).

[https://gist.github.com/manuel-
colmenero/94c53afbb3a167c6e76...](https://gist.github.com/manuel-
colmenero/94c53afbb3a167c6e769)

recieve:

    
    
        ./vimfifo pipe
    

send:

    
    
        echo 'ls' > pipe
    

(note that the command is runned in the "recieving end", so that vim doesn't
block)

~~~
jmcphers
Have you seen dispatch.vim? It makes it easy to dispatch commands from Vim to
a tmux split, etc.

[https://github.com/tpope/vim-dispatch](https://github.com/tpope/vim-dispatch)

~~~
kolme
Yes, and I also use it, but :Dispatch takes the output to the error list, and
:Start doesn't display the output (ot waits for promt).

With this script I can have the following layout:

    
    
        .-----------------.
        |        |        |
        |  Vim   | output |
        |        |        |
        |        |        |
        `-----------------'
    

I usually do this when editing a script, for a quick edit-run feedback. For
example:

    
    
        :update | RunFifo bash %
    

Runs the script and displays the output on the side. And then for saving and
re-running the same command is just:

    
    
        @:

------
wocram
Seems like an overcomplicated solution to something zshell supports directly
:)

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.

[http://arjanvandergaag.nl/blog/customize-zsh-prompt-with-
vcs...](http://arjanvandergaag.nl/blog/customize-zsh-prompt-with-vcs-
info.html)

------
joshguthrie
Today in: Problems nobody ever had.

------
2ton_jeff
Mosh has this fully sorted too IMO:
[https://mosh.mit.edu](https://mosh.mit.edu)

~~~
karlshea
I thought of Mosh when I saw this, too, but unless I'm mistaken they seem to
be two different things.

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).

------
zobzu
you could also just type '&' at the end of each command ;-)

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

