Passo 3 · Módulo 2 · Traduzir · Módulo 2 · Traduzir · Fish, Starship e a linha que decide tudo
Do guia da Rocketseat ao Warp · Visual Course

Fish, Starship e a linha que decide tudo

Você pode seguir o guia inteiro e não ver diferença nenhuma. Esta lição mostra por quê — e como provar, lendo o ambiente do processo, que o prompt do Starship está mesmo ligado no Warp.

Leia primeiro (fonte primária)
Starship — o prompt multi-shell, em Rust

A fonte primária do prompt que o guia recomenda. Esta lição destila como ele conversa com o fish e o que o Warp faz por cima dessa conversa.

Leia a versão simples, ou abra a camada técnica em qualquer seção.
1

A grande ideia


O Warp desenha o próprio prompt. Ele é bonito e integrado — e, por padrão, ele ignora o prompt que o seu shell imprime. Instalar o Starship com o Warp nesse padrão dá zero resultado visível: tudo certo, nada aparece.

Pense como… instalar um som novo no carro sem perceber que o rádio de fábrica continua ligado no alto-falante. O som toca, mas ninguém ouve.

Quando o Warp abre uma sessão, ele injeta variáveis no processo do shell. Uma delas é WARP_HONOR_PS1, derivada de terminal.input.honor_ps1. Com 0, o Warp suprime o prompt do shell e desenha o dele; com 1, ele imprime o que o shell mandar — que no fish inicializado com starship init fish | source é a função fish_prompt. Como a variável é injetada no spawn, ela vale por sessão: mudou o arquivo, a próxima aba nasce com o valor novo.

honor_ps1 está true? sim Prompt do Starship WARP_HONOR_PS1=1 não Prompt nativo do Warp WARP_HONOR_PS1=0 Instalar starship com honor_ps1=false = trabalho invisível.
A decisão que define se o Starship aparece ou não.
QUEM DESENHA O SEU PROMPT Warp — decide se mostra o prompt do shell honor_ps1 fish — chama fish_prompt a cada Enter config.fish starship — monta a string do prompt starship.toml módulos — directory, git, nodejs, character $format
As quatro camadas entre você e o prompt. A de cima pode anular todas as outras sem erro nenhum.
O TAMANHO DO PULO DO GATO 1 linha que decide 0→1 WARP_HONOR_PS1 6 módulos no prompt 0 reinícios necessários
A escala do problema: uma linha, uma variável, nenhum reinício — e um sintoma que parece grande.
Ao fim desta lição você consegue
  • Entender por que o Starship pode estar instalado e invisível
  • Ligar honor_ps1 e provar o efeito lendo o ambiente do processo
  • Saber a ordem de carregamento do fish: conf.d/ antes de config.fish
  • Ler o prompt do Starship módulo a módulo
2

O fish, e a ordem em que ele carrega


O guia elogia o fish pela sintaxe limpa e pelo autocompletar. Para configurá-lo bem, o que importa é a ordem: o fish lê tudo em conf.d/ antes do config.fish.

COMO UMA SESSÃO FISH NASCE conf.d/*.fish ordem alfabética config.fish o seu arquivo fish_prompt starship aliases, env PATH, init a cada Enter
A ordem de carregamento de uma sessão fish. Quem coloca PATH no conf.d descobre isso do jeito difícil.

As duas linhas que o guia pede. O command -q evita erro em máquina onde a ferramenta não existe.

~/.config/fish/config.fish
if command -q starship
    starship init fish | source
end

if command -q zoxide
    zoxide init fish | source
end

Como chegar: bat ~/.config/fish/config.fish. O starship init fish define a função fish_prompt; é ela que o fish chama a cada prompt.

A ÁRVORE DE CONFIGURAÇÃO DO FISH ~/.config/fish/ [intacto] └─ conf.d/*.fish lido primeiro, ordem alfabética [intacto] └─ conf.d/rocketseat.fish a camada de plugins [novo] └─ config.fish PATH, starship init, zoxide init [intacto] └─ functions/<nome>.fish autoload sob demanda [intacto] ~/.config/starship.toml o formato do prompt [editado]
Onde cada coisa mora no fish. Quem entende esta árvore não erra mais a ordem de carregamento.

Manter a implementação num arquivo próprio (conf.d/rocketseat.fish) torna o rollback trivial: apagar um arquivo desfaz 100% da camada, sem editar nada que já existia. É a mesma razão pela qual starship init ficou onde estava — mexer no config.fish do usuário seria misturar o que veio do guia com o que já era dele.

3

Em uma imagem


o prompt, renderizado de verdade probe-repo on main [!] via v25.9.0 is v1.0.0 ❯
O prompt real gerado nesta máquina, num repositório git com Node e package.json. Cada pedaço é um módulo do starship.toml.
ANATOMIA DO PROMPT diretório probe-repo git main [!] sujo runtime v25.9.0 pacote v1.0.0
O mesmo prompt, decomposto. Cada raia é um módulo que só aparece quando o contexto pede.

A ordem do format é a ordem na tela. Cada módulo tem um símbolo, e o símbolo precisa existir na fonte.

~/.config/starship.toml (trecho)
format = """
$directory\
$git_branch\
$git_status\
$nodejs\
$package\
$character
"""

[character]
success_symbol = '[❯](bold green)'
error_symbol = '[❯](bold red)'

[git_branch]
symbol = " "

[git_status]
ahead = '↑${count}'
diverged = '↕↑${ahead_count}↓${behind_count}'
behind = '↓${count}'

Como chegar: bat ~/.config/starship.toml · starship explain mostra por que cada módulo apareceu.

OS GLIFOS DESTE PROMPT NF U+E0A0 git branch na fonte NF U+E718 node na fonte NF U+F487 package na fonte U+276F character na fonte U+2191 ahead (novo) na fonte U+21E1 ahead (antigo) AUSENTE
Os símbolos que este prompt emite, checados contra a fonte da lição 2. As caixas NF são ícones da Nerd Font: eles existem no terminal, mas não nesta página — o navegador não tem a fonte instalada.
QUANTO CADA MÓDULO CUSTA directory 1 ms git_branch 6 ms git_status 14 ms nodejs 9 ms package 4 ms
Custo típico por módulo, em milissegundos. starship timings mostra os seus — git_status costuma liderar porque toca o disco.
As setas de git_status começaram como ⇡ ⇣ ⇕. Por que foram trocadas por ↑ ↓ ↕?
Porque U+21E1, U+21E3 e U+21D5 não existem no cmap da JetBrainsMono Nerd Font. Elas cairiam em fallback de outra fonte, com largura diferente, desalinhando o prompt. A lição 5 mostra a auditoria que encontrou isso.
4

honor_ps1: o pulo do gato


Uma linha. É literalmente uma linha de arquivo que separa "instalei o Starship e não mudou nada" de "o prompt do guia apareceu".

UMA LINHA, DOIS MUNDOS antes — Starship invisível [terminal.input] honor_ps1 = false $ echo $WARP_HONOR_PS1 0 → prompt nativo do Warp depois — Starship na tela [terminal.input] honor_ps1 = true $ echo $WARP_HONOR_PS1 1 → prompt do starship
A mudança inteira, e o efeito observável no ambiente da sessão.

honor_ps1 = true manda o Warp imprimir o prompt do shell em vez do dele.

~/.warp/settings.toml
[terminal.input]
input_box_type_setting = "classic"
honor_ps1 = true

Como chegar: Pela interface: Settings > Features > Terminal > "Honor user's custom prompt (PS1)".

terminal — provando honor_ps1 no boundary real $ pgrep -f WARP_SESSION_ID # sessoes antes 40892 46153 $ open -a Warp ~/Documents/Projects/rocketseat-warp $ ps eww -o command= -p 99641 | tr ' ' '\n' | grep WARP_HONOR WARP_HONOR_PS1=1
A prova real: abrir uma aba nova e ler o ambiente que o Warp injetou no processo filho. A sessão antiga continua com 0 — a variável vale por sessão.
DE UMA LINHA ATÉ A EVIDÊNCIA Editar honor_ps1 = true Warp relê a quente Aba nova spawn do shell Provar ps eww settings.toml sem reiniciar injeta env WARP_HONOR_PS1=1
Os quatro passos entre editar e provar. O terceiro é obrigatório: a variável entra no nascimento da sessão.
prompt nativo do Warp Integrado aos blocos e à busca Zero configuração Mesmo visual em qualquer máquina Não mostra git/runtime por padrão Não é o que o guia pede prompt do Starship Módulos por contexto (git, node, python) Mesmo prompt em qualquer terminal Configurável em um TOML Depende de fonte com ícones É o que o guia pede escolha do guia: starship
Os dois são defensáveis. O guia escolheu o segundo — e no Warp isso exige uma linha explícita.

Ver honor_ps1 = true no arquivo prova que você escreveu a linha, não que o Warp a aplicou. As duas coisas se separam quando o app cacheia configuração, quando há um perfil por workspace, ou quando o arquivo tem erro de sintaxe e o app cai no padrão. Ler WARP_HONOR_PS1 no processo filho fecha esse buraco: é o próprio Warp dizendo o que decidiu.

5

Experimente


Fazer o Starship aparecer no seu Warp
1
Confirme o fish como shell da sessão: session.new_session_shell_override.executable
2
Confirme o init: fish -lic 'functions -q fish_prompt' deve sair com status 0
3
Ponha honor_ps1 = true em [terminal.input]
4
Abra uma aba nova e rode echo $WARP_HONOR_PS1 — precisa dizer 1
Agora você: rode starship explain nessa aba e veja, módulo a módulo, por que cada pedaço do seu prompt apareceu.
DO SPAWN AO PRIMEIRO ❯ Warp spawn fish -l 1 conf.d/ aliases, env 2 config.fish starship init 3 fish_prompt definida 4 Warp decide honor_ps1 5 você vê 6
O ciclo de vida de uma sessão, do spawn até o cursor. O passo 5 é onde o trabalho dos passos 2–4 pode ser jogado fora.

O sintoma

"Instalei o Starship, segui o guia inteiro, e o prompt continua o do Warp."

Nada está quebrado. O shell está imprimindo o prompt certo — o terminal é que não está mostrando.

O diagnóstico em um comando

echo $WARP_HONOR_PS1

Se responder 0, achou. Se responder vazio, você não está numa sessão do Warp.

A correção

honor_ps1 = true em [terminal.input] do ~/.warp/settings.toml.

O Warp relê o arquivo a quente: abra uma aba nova, não precisa reiniciar o app.

O trade-off honesto

Com o prompt do shell ligado, você troca o prompt nativo do Warp pelo do Starship. Os blocos, a busca e os workflows continuam funcionando.

Voltar é a mesma linha em false.

1 / 4
Revisão da lição 3
Starship instalado, fish rodando, e o prompt do Warp continua o nativo. O que checar primeiro?
b está certa: é o teste de um comando que separa "o shell não imprime" de "o terminal não mostra". a vale se o prompt aparecer torto, não se ele não aparecer. c explicaria quadradinhos no lugar dos ícones — sintoma diferente.
Você mudou honor_ps1 com o Warp aberto. Quando o valor vale?
c está certa: a variável é injetada no spawn do shell, então vale por sessão nova. a é pessimista — foi provado que uma aba nova basta. b é otimista: a aba antiga guarda o ambiente com que nasceu.
Com o prompt na tela, falta a camada que o guia chama de "plugins e integrações". É a próxima lição — e é onde a paleta Vesper reaparece três vezes.