Cómo configurar tu terminal y dotfiles desde cero

La mayoría de los desarrolladores pasan el 30% o más de su tiempo laboral en la terminal. Y la mayoría de ellos trabajan con la configuración que venía por defecto, sin personalizar absolutamente nada.

Eso es como pasar ocho horas al día en una silla de plástico cuando hay una ergonómica disponible por el mismo precio.

Este artículo te enseña a configurar tu entorno de línea de comandos de forma seria: shell, prompt, dotfiles con control de versiones, y las utilidades modernas que reemplazan comandos clásicos con versiones 10 veces más usables. Todo esto aplica en macOS y en cualquier distribución Linux.

Para el ecosistema completo de herramientas de desarrollo, visita Programación en Geekshop.

Por qué tu terminal importa más de lo que crees

La terminal no es solo una forma de correr comandos. Es el punto de integración de casi todo lo que haces como desarrollador: controlas Git, ejecutas scripts de build, manejas servidores, procesas datos, te conectas a contenedores remotos. Es la interfaz más eficiente que existe para un profesional técnico porque elimina capas de abstracción gráfica que consumen tiempo.

Un entorno de terminal bien configurado te da:

• Velocidad: atajos, autocompletado inteligente, navegación por historial
• Contexto: saber en qué branch de Git estás, cuánto tarda el último comando, el estado de tu virtualenv
• Reproducibilidad: cuando renueves tu máquina o trabajes en un servidor remoto, tu configuración puede estar disponible en minutos

Un entorno mal configurado o sin configurar te hace más lento sin que lo notes.

Configura un prompt que te dé contexto real

El prompt por defecto te dice en qué directorio estás. Un buen prompt te dice mucho más: la rama de Git, si hay cambios sin commitear, el tiempo que tardó el último comando, el virtualenv activo, el estado de conexión a un servidor remoto.

Starship: el prompt cross-shell más popular hoy

Starship es un prompt escrito en Rust, extremadamente rápido, y que funciona en bash, zsh y fish sin cambiar el shell. Detecta automáticamente el contexto: Python virtualenv, versión de Node en uso, rama Git, estado de Docker.

La instalación es simple:

# macOS con Homebrew
brew install starship

# Linux (instala en ~/.local/bin)
curl -sS https://starship.rs/install.sh | sh

Luego agregas al final de tu archivo de configuración del shell (~/.zshrc para zsh):

eval "$(starship init zsh)"

La configuración vive en ~/.config/starship.toml. El archivo de configuración es declarativo y bien documentado.

~/.dotfiles/
├── git/
│   └── .gitconfig
├── shell/
│   ├── .zshrc
│   └── .aliases
├── starship/
│   └── starship.toml
├── nvim/
│   └── init.lua
└── install.sh

Herramientas especializadas para dotfiles

Si quieres algo más sofisticado que symlinks manuales:

• GNU Stow: gestiona los symlinks automáticamente siguiendo la estructura de directorios
• chezmoi: más potente, permite templates (configs que varían por máquina), cifrado de secretos, y sincronización multi-máquina
• dotbot: declarativo con YAML, fácil de entender y auditar

Para la mayoría de los casos, symlinks manuales o GNU Stow son suficientes.

Las herramientas CLI modernas que deberías adoptar

Los comandos Unix clásicos (ls, cat, find, grep) fueron diseñados décadas atrás. Hay reemplazos modernos —muchos escritos en Rust o Go— que son más rápidos, tienen mejor output por defecto y más funcionalidades.

zoxide merece mención especial porque cambia fundamentalmente cómo navegas por el sistema. En lugar de:

cd ~/Development/proyectos/cliente-x/backend/src/api

Escribes simplemente:

z api

Y salta al directorio correcto basándose en frecuencia de visita. Si tienes múltiples coincidencias, muestra una lista interactiva.

# Historial
HISTSIZE=10000
HISTFILE=~/.zsh_history
SAVEHIST=10000
setopt HIST_IGNORE_DUPS
setopt SHARE_HISTORY

# Autocompletado
autoload -Uz compinit && compinit

# Aliases esenciales
alias ls='eza --icons'
alias ll='eza -la --icons'
alias cat='bat'
alias grep='rg'
alias find='fd'

# Variables de entorno
export EDITOR='nvim'

# Zoxide
eval "$(zoxide init zsh)"

# Starship prompt (al final siempre)
eval "$(starship init zsh)"

Errores comunes al configurar tu terminal

Siguientes pasos lógicos

Una vez que tengas tu terminal configurada con los fundamentos explicados aquí, el siguiente nivel natural es elegir y dominar tu editor. Ese es uno de los temas que cubrimos en las herramientas que de verdad usan los desarrolladores: la diferencia entre editor e IDE, cómo evitar la trampa de sobre-configurar antes de saber programar, y qué herramientas del ecosistema completo valen realmente la inversión de tiempo.

FAQ

¿Necesito instalar todo esto para aprender a programar?

No. Si apenas estás empezando con tu primer lenguaje de programación, una terminal básica es suficiente. La configuración avanzada es para quienes ya pasan horas diarias en la terminal y quieren sacar más eficiencia. Prioriza aprender a programar antes de optimizar el entorno.

¿Cuál es el mejor emulador de terminal?

En macOS: Ghostty (2024) o WezTerm son las opciones modernas más recomendadas. iTerm2 sigue siendo sólido pero más pesado. En Linux: Alacritty para velocidad pura, kitty si quieres extensiones, la terminal nativa de tu DE si quieres cero fricción.

¿Para qué sirven los alias en el shell?

Para abreviar comandos que usas frecuentemente. alias gs='git status', alias gp='git push'. Te ahorran teclas pero también pueden volverte dependiente de tu propia configuración y confundirte en máquinas ajenas. Usa alias con criterio; no abrevies todo.

¿Dónde subo mis dotfiles?

GitHub o cualquier proveedor de Git. Si contienen secretos (tokens, contraseñas) — que no deberían estar en dotfiles — mantén el repo privado o usa chezmoi con cifrado. Lo recomendable es mantener los secretos fuera de los dotfiles completamente y referenciarlos via un gestor de secretos o variables de entorno que se configuran por separado.

¿Vale la pena aprender Vim/Neovim?

Si pasas mucho tiempo editando código en servidores remotos sin GUI, sí es esencial. Para desarrollo local, es una elección personal de editor. La curva de aprendizaje es real pero quienes lo dominan reportan ser significativamente más rápidos en tareas de edición. No es para todos y no está mal reconocerlo.