Bash Prompts Collection | Hacker News Reader

Bash Prompts Collection

gilesorr.com

66 pointsgiulianopz30 comments

I strongly recommend against putting a ">" in your prompt on Unix if you're using any kind of system that supports copy and paste. (So, like, on a physical VT100 on a serial port it would be okay.) Sooner or later you're going to take a prompt-included command like

    > ls GN*

and accidentally paste it into a terminal window (or a web page that someone else pastes into a terminal window) and accidentally create an empty file named "ls". Or, in some cases, overwrite an existing file.

My own current setting is

    PS1=': ${env:+($env) }\W; '

Which looks like this:

    : ~; cd wak
    : wak; ls
    LICENSE   monosrc    scripts  toybox            toybox_awk_test
    Makefile  README.md  src      toybox_awk_parts
    : wak;

The :; has the advantage that, if you unintentionally include the prompt in your copy and paste, it usually has no effect. (Maybe I should change ($env) to [$env].) \W (the last segment of the directory name) is usually about the right amount of context for me, but if I were working on a project with a lot of directories named things like "views" I would probably reconsider that.

BTW, since this prompt collection was written, Linux terminal emulators have mostly gained 24-bit color support, which potentially opens up more alternative colors. See http://canonical.org/~kragen/sw/dev3/gradient.c with sample results in http://canonical.org/~kragen/sw/dev3/gradient.png. The escape sequence is \033[38;2;rrr;ggg;bbbm, where \033 is ESC and rrr, ggg, and bbb are decimal numbers from 0 to 255.

(Probably I should switch from bash to zsh...)

I use Linux for 30 years. Never had this problem. However, I saw newbies, which copy paste commands from tutorials to shell and then frustrated, because # is a comment.

I bet you've never accidentally rm -rf'ed your home directory or your email archives either.

> I bet you've never accidentally rm -rf'ed your home directory or your email archives either.

If this is a concern to mitigate, consider adding the following alias to your preferred shell profile:

  alias rm='/bin/rm -I'

This will not conflict with scripts using PATH-relative 'rm' invocations, yet will provide the desired protection from erroneous interactive use of "rm -rf".

See here[0] for details regarding the '-I' flag.

0 - https://linux.die.net/man/1/rm

This would have helped when I `rm -rf`ed my home directory, but I was on Ultrix, whose `rm` didn't have the `-I` flag. In fact, I don't think even GNU `rm` had `-I` yet. I was in /tmp/something where I'd unpacked some software package I'd downloaded and decided was of no use, and I wanted to read netnews, so I typed

    rm -rf * & cd; trn

Several hours later, around 3 AM, I was done reading netnews, so I exited trn. Then I remembered that there was one newsgroup I had forgotten to read, so I typed ↑↵ to run trn again, which had the effect of again running

    rm -rf * & cd; trn

but this time in my home directory. And of course my frantic ^C^C^C had no effect on the `rm`, which was safely in the background.

Fortunately the computer center kept nightly backups.

I alias rm='rm -i', and then check that I'm deleting the right thing. And then redo the command with `yes | rm -r whatever`. This ends up giving me an "audit log" of what was deleted.

I do

rm /dir

Then go back and add the -rf.

Works on GNU and BSD. On GNU only you can

‘rm /dir -rf’

> I strongly recommend against putting a ">" in your prompt on Unix ...

Another reason against using ">" in the definition of PS1 is that this is a typical character used in the definition of PS2[0].

> The :; has the advantage that, if you unintentionally include the prompt in your copy and paste, it usually has no effect.

This is because colon (':') has a specific definition in POSIX shells[1], which is:

  Do nothing beyond expanding arguments and performing 
  redirections. The return status is zero.

Note that "performing redirections" can result in destructive file operations.

0 - https://unix.stackexchange.com/questions/193659/in-which-sit...

1 - https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh...

Right, I shouldn't assume that everyone knows what the `:` command does. I'm not especially worried about destructive file operations in this context because I don't think any of my directories has a `>` in its filename.

You can avoid this by using Unicode character U+276F "Heavy Right-Pointing Angle Quotation Mark Ornament", which also looks better IMHO.

I find it’s very valuable to have a time Delta in the prompt. Knowing how long something normally takes can help you catch situations where your five second test run turns into a 30 second test run very easily.

Adopted:

  https://atuin.sh/
  https://github.com/akinomyoga/ble.sh
  https://starship.rs/

These three have made my shell game so much more enjoyable.

Can’t agree more.

atuin in particular records the history of each command but also how long they took and is they were successful or not.

You never have to rerun a command with long output to know how long it took: just ctrl-r and see.

Like most customization and command replacements (like the fancy greps, ls's, etc), I've stopped using fancy prompts because I log in to lots of systems over the day and most of them won't have my prompt and this causes annoyance.

Also I have a theory that it lowers chatbot performance if you're copy pasting terminal output.

I feel you, though this is why it's quite useful to have your own repo (or even just a dot file you can scp) with your dots files in them so you can "move in" to any machine and feel at home. Just clone/scp, then run your move in script.

This also applies to say vimrc (choose your editor/tool of choice).

About that last part, what do you mean exactly?

One thing that comes to mind is it might make its output more aligned with data that includes the full terminal output, which could make it more copy-pastey?

I mean that chatbots might have an easier time working with terminal output with the standard prompt rather than one that has your battery, weather, git branch and aws account in it.

It's just an idle thought though.

Seems perfectly reasonable. Everything unrelated is an opportunity to go off the rails.

Missing from all of these: Error code returned from previous command. Invaluable.

Absolutely! Not only does filtering on $? provide info (last command interrupted, suspended, good, bad, etc.), it makes the prompt itself a quick way to test [[ ... ]] expressions....

(My prompt is platform aware since codes for some ops differ between MacOS and Linux. The return is colour-coded (green, red, purple, depending on case), and multiline, with git status if in a repo, cwd, and a few other things....)

Dan's Prompt includes the exit code

My buddy spike723 on EFnet built what I can only describe as a sentinent bash prompt. I recall it being massive and could show you everything about your system in a prompt.

25 years later I have no clue where this guy went but I remember him because he was instrumental in moving me off zsh to bash

Right on, I've always enjoyed tinkering with my own `$PS1`. Why did you move from zsh to bash -- what bash features pulled you over?

This was 20 years ago, but what I found was that bash is on every system. Too many shells would only have bash (or ksh) where my zsh profiles were useless. Fast forward to today and I’m hard pressed to find any containers with anything but Bourne. So bash it is!

Understood. I learned this way too, stick with a near universal standard/expectation, especially if you want to script for it and customize and if you are accessing remote machines often so you can be comfortable and productive in any situation.

P.S. just fully noticed your handle, very shell discussion appropriate! :)

I was a bit surprised only one of them included showing if the last command succeeded or not. My $ being green if ok red otherwise is one of the few things I miss when using a stock prompt.

For bash users I can recommend looking into setting PS1 from a function and assigning that function to PROMPT_COMMAND as it makes it much easier to make it readable

Now this is prompt engineering.

you can spot a journey man by the lack of last command exit code on the bash prompt.

Another idea: an indication of how many background jobs are currently running. With many terminal tabs open, I can forget if I already have $EDITOR (or something else) running, so the number of jobs can be a nice cue.

    _jobscount() {
        local jobs=($(jobs -p))
        local count=${#jobs[@]}
        (($count)) && echo -n " (${count}j)"
    }

And then put that in your prompt.

ty giles

Reply on news.ycombinator.com