Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bash Prompts Collection

gilesorr.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Bash Prompts Collection

#11

Post by nailer »

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.

Re: Bash Prompts Collection

#13

Post by dpflan »

grepfru_it wrote: post #10

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?

Re: Bash Prompts Collection

#14

Post by dpflan »

okasaki wrote: post #3

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

Re: Bash Prompts Collection

#15

Post by kragen »

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

Re: Bash Prompts Collection

#16

Post by oneshtein »

kragen wrote: post #15

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…

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.

Re: Bash Prompts Collection

#18

Post by kragen »

oneshtein wrote: post #16
kragen wrote: post #15

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…

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.

Re: Bash Prompts Collection

#19

Post by procaryote »

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

Re: Bash Prompts Collection

#20

Post by PeterWhittaker »

everybodyknows wrote: post #17

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

Post reply on HN