this post was submitted on 15 Jul 2023
27 points (100.0% liked)

Shell Scripting

1362 readers
1 users here now

From Ash, Bash and Csh to Xonsh, Ysh and Zsh; all shell languages are welcome here!

Rules:
  1. Follow Lemmy rules!
  2. Posts must relate to shell scripting. (See bottom of sidebar for more information.)
  3. Only make helpful replies to questions. This is not the place for low effort joke answers.
  4. No discussion about piracy or hacking.
  5. If you find a solution to your problem by other means, please take your time to write down the steps you used to solve your problem in the original post. You can potentially help others having the same problem!
  6. These rules will change as the community grows.

Keep posts about shell scripting! Here are some guidelines to help:


In general, if your submission text is primarily shell code, then it is welcome here!

founded 1 year ago
MODERATORS
 

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!

you are viewing a single comment's thread
view the rest of the comments
[–] kartoffelsaft 1 points 1 year ago (3 children)

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'

hintsome of the escape sequences move the cursor

full explanationgenerates 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 3 points 1 year ago* (last edited 1 year ago) (2 children)

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 2 points 1 year ago* (last edited 1 year ago) (1 children)

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