An Asynchronous Shell Prompt | Hacker News Reader

An Asynchronous Shell Prompt

anishathalye.com

62 pointsgabamnml21 comments

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

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.

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

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

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.

Per the other response, this isn't delaying the cd, it's completing the cd and then delaying the loading of ancillary information to display asynchronously.

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.

_Edit:_ Replies below are right, it has to run the commands sequently for it to actually work somehow.

Either way, it doesn't make much sense to me. For example, if `cd` fails you need to go back a few steps, etc.

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.

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.

Another example: https://github.com/sindresorhus/pure

This uses zsh-async: https://github.com/mafredri/zsh-async

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

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.

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.

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

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

recieve:

    ./vimfifo pipe

send:

    echo 'ls' > pipe

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

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

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:

@:

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

Today in: Problems nobody ever had.

Mosh has this fully sorted too IMO: https://mosh.mit.edu

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

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

Reply on news.ycombinator.com