1. 25
  1.  

  2. 9

    Starship is the minimal, blazing fast, and extremely customizable prompt for any shell!

    What makes this minimal? As far as I can tell, it’s anything but minimal.

    1. 4

      cargo.lock is barely more than 1000 lines. That’s tiny!

    2. 5

      Starship is the minimal, blazing fast, and extremely customizable prompt for any shell!

      As long a said shell is one of bash, fish or zsh.

      1. 15

        Your point is fair, because installing for Fish/Bash/Zsh is all they explain; but I’m not sure it’s accurate, because Starship’s core is indeed shell-agnostic AFAICT. Below is the core call. It prints the colourized prompt for the current user/host/directory, which is what every shell’s prompt function must boil down to. Starship’s shell-specific initialisations provide code to compute $cmd_duration etc. for every prompt, but in the end they all make the core call.

        starship prompt \
            --status=$exit_code \
            --keymap=$keymap \
            --cmd-duration=$cmd_duration_in_seconds \
            --jobs=(jobs -p | wc -l)
        

        All those flags are optional, if you shell doesn’t store command duration or whatever.

        To prove this particular shelly pudding, I edited my ~/.tclshrc to look mostly as follows:

        if {$tcl_interactive} {
        
            package require tclreadline
        
            namespace eval tclreadline {
                proc prompt1 {} {
                    return [exec starship prompt]  # <-- Starship here
                }
            }
            # go to tclrealdine's main loop.
            tclreadline::Loop
        }
        

        That got me the Starship prompt in my Tcl REPL. And cd’ing to a Git repository got the Starship prompt to display information on Git’s dirtyness, active branch, and all that jazz. So yes, as long as your shell’s prompt-function can call external programmes, and is running in a VT100 terminal emulator, and that terminal emulator has a Powerline font installed to render the fancy characters — Starship will work for that shell!

        1. 7

          Oh, well in that case, I’m happy to be proven wrong. I do wish they had a section along the lines of

          For other shells, the command starship prompt may be used to generate the prompt, but setting it depends on the shell itself.

          if only to prevent my embarassing myself with a kneejerk response.

          1. 3

            Noted!

            We will be writing up some docs on how to write your own starship wrapper for your shell of choice.

        2. 6

          tcsh users unite. (My default shell since 1995.)

          1. 5

            Similar to how “portable” these days mostly means “works on Windows, macOS and GNU/Linux [sometimes musl/busybox/Linux by accident]” these days, I guess. Not that it’s a good thing, but I can see how they’d arrive at that marketing claim.

            1. 1

              Works on the most common shells on the most common operating systems.

              ?

              1. -2

                And people use some strictly posix shell interactively as their preferred shell?

                get real.

                1. 10

                  Who said anything about strictly posix? There’s quite a few BSD users and developers on here. OpenBSD for example uses ksh as a default, and its version of ksh has even been ported to various linux distros (under oksh or loksh, usually). FreeBSD uses tcsh, and NetBSD (IIRC) ash.

                  1. 2

                    Your parent comment was just plainly POSIXLY_INCORRECT

                  2. 5

                    I use eshell as my preferred shell.

                2. 5

                  I’m waiting on an async prompt (not sure if this is or isn’t, but seeing as they’re not bragging about it I’m assuming it’s not). I like having git info (and such) in my shell, but I invariably get into some enormous repository and suddenly my prompt takes 10 seconds to display because it’s stuck running git status or similar.

                  Would dispatching a process but allowing it to keep printing to the console (via, I suppose, curses?) even work?

                  1. 4

                    Async fork here: https://github.com/maximbaz/spaceship-prompt

                    Not tried it myself but it sounds good. I’m using fish for the moment as it just seems to be speedy enough everywhere.

                    1. 3

                      For the time being, there’s no support for async prompts directly baked into starship. That said, it would be possible to write an async prompt wrapper for starship in zsh using zsh-async or in fish using fish-async-prompt, since prompt modules can be rendered individually with starship module <module_name>.

                      We have plans to write async wrappers for shells, though it’s not high on our priority list right now. Contributions are welcome! :)

                      1. 2

                        zsh’s vcs-info library works pretty fast for me.

                        I’ve only had to have workarounds on ssh mounts.

                      2. 3

                        Is this faster or slower than Fish’s built-in VCS monitoring?