Portál AbcLinuxu, 2. května 2025 07:14
Pěkný hack, ale má to jednu drobnou vadu – když mačkám enter, aniž bych psal nějaký příkaz, mám tučně i prompt (nevyšle se DEBUG signál, který by nastavil písmo na normální).
Snadná oprava:
export PS1="\e[0m$PS1\[$(tput bold)\]" trap 'echo -ne "\e[0m"' DEBUG
$()
, protože forkuje při každým zobrazení PS1, 2) PS2 je bold, ale ne že by to vadilo, dá se to samozřejmě pořešit...
export PS1="\e[0m$PS1\e[1m" export PS2="\e[0m$PS2\e[1m" trap 'echo -ne "\e[0m"' DEBUG
PROMPT_COMMAND
se evaluuje (to je krásný češtin $()
, tak by forkovat neměl...
GREEN="\e[1;32m" RED="\e[1;31m" WHITE="\e[m" EXIT_COLOR(){ printf -- "$(_dir_chomp "$(pwd)" 40)," [[ 0 == "$1" ]] && printf -- "$GREEN$1" || printf -- "$RED$1"; printf -- "$WHITE$" } _dir_chomp () { local IFS=/ c=1 n d local p=(${1/#$HOME/\~}) r=${p[*]} local s=${#r} while ((s>$2&&c<${#p[*]}-1)) do d=${p[c]} n=1;[[ $d = .* ]]&&n=2 ((s-=${#d}-n)) p[c++]=${d:0:n} done printf -- "${p[*]}" } PS1='\u:$(EXIT_COLOR $?) '
PROMPT_COMMAND
, kde se vyhneš těm subshellům. Mam to takhle:
_ret_ok=$(echo -e '\e[0;32m✔\e[0m')
_ret_bad=$(echo -e '\e[0;31m✖\e[0m')
PROMPT_COMMAND='[ $? -eq 0 ] && _ret="$_ret_ok" || _ret="$_ret_bad$?";'
PS1=' ${_ret} \D{%H:%M} \e[0;32m\u\e[0m \w \$ \e[1m'
PS2='\e[0m> \e[1m'
Screenshot.
_ret_ok
bych ještě přidal mezeru, aby to bylo zarovnané. A chybí mi tam název stroje.
printf "%3d" $exitcode
nebo něco takovýho.
_ret_ok=$'\e[0;32m✔\e[0m' _ret_bad=$'\e[0;31m✖\e[0m'
GREEN="\e[1;32m" RED="\e[1;31m" WHITE="\e[m" DIR_CHOMP(){ local IFS=/ c=1 n d local p=(${1/#$HOME/\~}) r=${p[*]} local s=${#r} while ((s>$2&&c<${#p[*]}-1)) do d=${p[c]} n=1;[[ $d = .* ]]&&n=2 ((s-=${#d}-n)) p[c++]=${d:0:n} done printf -- "${p[*]}" } EXIT_COLOR(){ DIR_CHOMP "$PWD" 40 printf -- "," [[ 0 == "$1" ]] && printf -- "$GREEN$1" || printf -- "$RED$1"; printf -- "$WHITE$" } PS1='\u:`EXIT_COLOR $?` 'Zdá se mi to subjektivně rychlejší.
Proč funkce EXIT_COLOR() řeší adresáře? Minimálně bych ji přejmenoval na něco výstižnějšího, když už to má být takhle v jedné funkci.
Proč funkce EXIT_COLOR() řeší adresáře? Minimálně bych ji přejmenoval na něco výstižnějšího, když už to má být takhle v jedné funkci.Funkce
EXIT_COLOR()
neřeší adresáře, řeší výpis $?
+ barvy. To volání adresářové funkce je nutné z EXIT_COLOR()
, protože kdyby došlo k volání DIR_CHOMP()
dříve, tak už by se nedostala k return value. Šla by tam přidat ještě třetí funkce, která to všechno poskládá dohromady, ale to už se mi zdá zbytečné.
Jinak to chce místo PS1='\u:`EXIT_COLOR $?` 'použít
PS1='\u:\[`EXIT_COLOR $?`\] 'jinak to silně blbne na konci řádku.
To volání adresářové funkce je nutné z EXIT_COLOR(), protože kdyby došlo k volání DIR_CHOMP() dříve, tak už by se nedostala k return value.
Však ona ta struktura může zůstat stejná, jen bych to prostě přejmenoval – když si čtu PS1
a vidím tam nějaký EXIT_COLOR $?
, tak čekám, že to asi vypíše obarvený kód – a ejhle, ono to dělá ještě něco jiného. Tady na tom až tolik nesejde, protože je to kód na pár řádků resp. člověk to vidí hned nad tím, co to dělá, ale stejně…
\[blabla\]
platí pro všechny barvy, i ty co máš definovaný výše, dělá to jinak nepředvídatelnej bordel (např. se nemůžeš vrátit kurzorem na začátek příkazu vytaženýho z historie a podobný prasečiny).
On by ale neměl počítat jen ty řídící sekvence, jiné znaky (text) ano.
Jak by mělo správně vypadat tohle?
export PS1="\e[0m$PS1\e[1m" export PS2="\e[0m$PS2\e[1m" trap 'echo -ne "\e[0m"' DEBUG
(to mi právě rozbilo editaci příkazů vytažených z historie)
GREEN="?\e[1;32m?" RED="?\e[1;31m?" WHITE="?\e[0m?" DIR_CHOMP(){ local IFS=/ c=1 n d local p=(${1/#$HOME/\~}) r=${p[*]} local s=${#r} while ((s>$2&&c<${#p[*]}-1)) do d=${p[c]} n=1;[[ $d = .* ]]&&n=2 ((s-=${#d}-n)) p[c++]=${d:0:n} done echo -ne "${p[*]}" } EXIT_COLOR(){ DIR_CHOMP "$PWD" 40 echo -n "," [[ $1 == 0 ]] && echo -ne "$GREEN$1" || echo -ne "$RED$1"; echo -ne "$WHITE" } COMMAND_PROMPT= PS1='\u:`EXIT_COLOR $?`\$ 'Podstatná je změněná definice
GREEN="?\e[1;32m?" RED="?\e[1;31m?" WHITE="?\e[0m?"To sice může vypadá stejně, ale hned za/před uvozovkama jsou vložené znaky s ASCII kódem 1 a 2, které dělají to samé co \[ resp. \], které se ale nedají vložit do toho volání funkce (zkoušel jsem všechno možné, nedají - vypadá to, že PS1 unescapuje ty znaky ještě před tím, než zavolá tu funkci, takže tam potom už nejsou). Pokud se nepodaří HTML přenos, tak si je můžete vyrobit v interaktivním pythonu stylem:
>>> print ">%s<" % chr(1) >?< >>> print ">%s<" % chr(2) >?<Zkopírovat a potom ručně odmazat > a <.
export PROMPT_COMMAND='. ~/.prompt'v ~/.prompt:
#!/bin/bash S=$? END="\[\e[0m\]" RED="\[\e[31;1m\]" CYAN="\[\e[36;1m\]" GREEN="\[\e[32;1m\]" YELLOW="\[\e[33;1m\]" if [[ $S -eq 0 ]]; then DOLLAR="${YELLOW}\$" else DOLLAR="${RED}\$" fi PS1="${CYAN}\u${END}@${RED}\h${END} ${GREEN}\w${END} ${DOLLAR}${END} "Vyhneš se subshellům a problémům s escapováním.
export PS1="\[\e[0m\]$PS1\[\e[1m\]" export PS2="\[\e[0m\]$PS2\[\e[1m\]"mezi \[ \] a včetně se nezeapočítívá, takže pokud to nemá šířku, musí se to mezi to zavřít…
Tak jsem narazil ještě na jeden problém:
$ echo ahoj ahoj $ (echo ahoj) ahoj $ (echo ahoj); ahoj $ time (date); echo ahoj So čen 7 21:26:45 CEST 2014 real 0m0.003s user 0m0.000s sys 0m0.003s ahoj
Výpisy po závorkách jsou tučně, i když by neměly.
\e[3C
. Teď záludná otázka: O kolik přesune znak sekvence \e[0C
? Správně tušíte, že nula není správná odpověď, protože 0 = "chci default" a pro sekvenci CSI C je default 1, takže to přesune znak o 1 doprava. Aby to bylo zábavnější, různé sekvence mají různé defaulty, někdy 0, někdy 1, myslimže nějaká sekvence má dokonce default 100.
Je ovšem možné vymyslet i mnohem zábavnější sekvence, např. tohle:
echo -e '\e7\e[2\e[?2l\eH\eC\e<\e[2K\e[7m\e+0\eo`\en HAHA \eo`\e8'
Jen tak vod voka říct, co tohle dělá, není úplně jednoduchý. Ale vyzkoušejte, nedělá nic špatnýho...
\e8
(GTK VTE-based terminály)
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.