I’m sure some of you have absolute monstrosities of sigils (I know I do, in my .zshrc alone). Post them without context, and try and guess what other users’s lines are. If you want to provide context or guess, use the markdown editor to spoiler-tag your guesses and explanations!

  • kartoffelsaft@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I have this in my laptop’s .bashrc

    PS1='\e[0m\n\e[40m[\e[32m\u\e[37m] [\e[31m\A \d\e[31m] [\e[33m`pwd`\e[37m]\e[K\n\e[K\n\e[1A'
    PS0='\e[0m\n'
    
    hint

    some of the escape sequences move the cursor

    full explanation

    generates the prompt:

    
    [username] [00:01 Thu Jan 1] [/home/username]

    with a slightly brighter/darker background (depending on terminal colors), while also resetting it to not effect the appearance of command outputs

    • \e[0m\n: new blank line
    • \e[40m: sets the background color for the prompt
    • [: literal text
    • \e[32m\u\e37m: username in green, reset color for brackets
    • ] [: literal text
    • \e[31m\A \d\e[31m: time/date in red, reset color
    • ] [: literal text
    • \e[33mpwd\e[37m: calls pwd, prints it in orange
    • ]: literal text
    • \e[K\n: fill the rest of the prompt line with the background
    • \e[K\n: fill the line where commands are typed with the background
    • \e[1A: move the cursor up so that it’s in the background-filled area

    I am colorblind so I may have gotten colors wrong, but that’s hardly where the interesting bit is.

    • o11c@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      1 year ago

      That doesn’t seem sensible. Moving the cursor will confuse bash and you can get the same effect by just omitting the last \n.

      Note that bash 5.0, but not earlier or later versions, is buggy with multiline prompts even if they’re correct.

      Your colors should use 39 (or 49) for reset.

      Avoid doing external commands in subshells when there’s a perfectly good prompt-expansion string that works.

      You seem to be generating several unnecessary blank lines, though I haven’t analyzed them in depth; remember that doing them conditionally is an option, like I do:

      #PS1 built up incrementally before this, including things like setting TTY title for appropriate terminals
      PS0='vvv \D{%F %T%z}\n'
      PS1='^^^ \D{%F %T%z}\n'"$PS1"
      prompt-command-exit-nonzero()
      {
          # TODO map signal names and <sysexits.h> and 126/127 errors?
          # (128 also appears in some weird job-control cases; there are also
          # numerous cases where $? is not in $PIPESTATUS)
          # This has to come first since $? will be invalidated.
          # It's also one of the few cases where `*` is non-buggy for an array.
          local e=$? pipestatus="${PIPESTATUS[*]}"
          # Fixup newline. Note that interactive shells specifically use stderr
          # for the prompt, not stdin, stdout, or /dev/tty
          printf '\e[93;41m%%\e[39;49m%'"$((COLUMNS-1))"'s\r' >&2
          # if e or any pipestatus is nonzero
          if [[ -n "${e/0}${pipestatus//[ 0]}" ]]
          then
              if [[ "$pipestatus" != "$e" ]]
              then
                  local pipestatus_no_SIGPIPE="${pipestatus//141 /}"
                  local color=41
                  if [[ -z "${pipestatus_no_SIGPIPE//[ 0]}" ]]
                  then
                      color=43
                  fi
                  printf '\e[%smexit_status: %s (%s)\e[49m\n' "$color" "$e" "${pipestatus// / | }" >&2
              else
                  printf '\e[41mexit_status: %s\e[49m\n' "$e" >&2
              fi
          fi
      }
      PROMPT_COMMAND='prompt-command-exit-nonzero'
      
      
      • kartoffelsaft@programming.dev
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        Moving the cursor will confuse bash and you can get the same effect by just omitting the last \n.

        When I was testing it I did not get the same effect. Instead it would only put the background behind what I had typed and not the whole line. Doing it now it seems to be working with the omission. I would assume it’s a terminal emulator bug because I believe I have changed emulators since I wrote it. I’ve now removed it, thanks for fixing a bug.

        Avoid doing external commands in subshells when there’s a perfectly good prompt-expansion string that works.

        I wanted my home directory to not get shortened to ~, and if there is some way to do that with \w it isn’t easy to find out how.

        Also, what’s the reasoning for avoiding it (besides it being idiomatic)? I’m sure there is one, but I don’t think I’ve run into it yet.

        You seem to be generating several unnecessary blank lines

        I just like the look of it, and I have the screen space to do it.

        • o11c@programming.dev
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          Two of the most expensive things a shell does are call fork and call execve for an external program. pwd is a builtin (at least for bash) but the former still applies. $PWD exists even if you don’t want that shortening; just like your backticks be sure to quote it once so it doesn’t get expanded when assigning to PS1.

          In general, for most things you might want to do, you can arrange for variables to be set ahead of time and simply expanded at use time, rather than recalculating them every time. For example, you can hook cd/pushd/popd to get an actually-fast git prompt. Rather than var=$(some_function) you should have some_function output directly to a variable (possibly hard-coded - REPLY is semi-common; you can move the value later); printf -v is often useful. Indirection should almost always be avoided (unless you do the indirect-unset bash-specific hack or don’t have any locals) due to shadowing problems (you have to hard-code variable name assumptions anyway so you might as well be explicit).