La terminal no muerde: comandos que te salvan la chamba

Son las 6:47 pm. Ya habías cerrado la laptop mentalmente y suena el WhatsApp del jale: “no compila en mi máquina”, “se cayó el servicio”, “¿me sacas un log rápido?”. Abres tu laptop ya medio guerrera, batería en 18% porque el multicontacto del cowork “desapareció”, y ahí está: la ventanita negra.

La terminal.

Al principio te intimida porque no perdona typos. Pero cuando traes un deadline encima, la terminal es lo que evita que te pongas a dar clic como si eso arreglara production. Es la diferencia entre “ahorita veo” y “ya quedó, dame 5”.

Qué te vas a llevar

• Ubicarte sin perderte en carpetas raras.
• Crear, copiar, mover y borrar archivos sin hacer un desastre.
• Buscar texto/archivos cuando el repo parece bodegón.
• Armar pipelines con pipes y redirecciones (aquí se pone bueno).
• Permisos sin caer en el vicio del sudo.
• Procesos y puertos: quién está corriendo y por qué tu app “ya está en uso”.
• SSH + transferencias rápidas para cuando te toca meter mano en un server.

Por qué esto sí pega en la vida real

No importa si haces frontend, backend, data, QA o soporte: siempre llega el día en que tienes que correr scripts (npm, pip, make, docker), leer logs, matar un proceso atorado o entrar a una VM.

Y acá entre nos: en México muchas veces el “servidor” es un VPS barato que alguien contrató en una madrugada, el cliente nomás quiere que “funcione”, y tú eres la persona que tiene que sacar un rollback en corto si algo se fue chueco.

La terminal no te vuelve “más hacker” por arte de magia. Te vuelve más rápido, más independiente y menos propenso a regarla por andar a ciegas.

Comandos que sí vas a usar (con ejemplos de verdad)

Nota rápida: esto es macOS/Linux (bash/zsh). En Windows, lo más parecido es WSL o Git Bash. PowerShell es otro stack, pero el mindset se comparte.

1) Saber dónde estás y qué hay alrededor

Tu mapa base:

pwd
ls
ls -la

• pwd: tu ubicación exacta.
• ls: lo que hay.
• ls -la: incluye ocultos y permisos. Ideal cuando “no aparece” el .env.

Moverte sin llorar:

cd /ruta/a/proyecto
cd ..
cd ~

• .. sube un nivel.
• ~ te manda a tu home.

Tip de supervivencia: si te sientes perdido, no adivines. Corre pwd y te regresas con calma.

2) Crear carpetas/archivos sin abrir mil cosas

mkdir logs
mkdir -p src/components/Button

touch README.md

• -p crea toda la ruta aunque falten carpetas.

Para ver contenido rápido:

cat package.json
less .env.example

• less aguanta archivos largos; sales con q.

3) Copiar, mover, renombrar y borrar (con colmillo)

cp .env.example .env
cp -r src src_backup

mv app.js app.old.js
mv dist/ /tmp/dist/

rm archivo.txt
rm -r carpeta/

Regla que me ha evitado tragedias: antes de un rm -r, haz ls. Neta. Es el equivalente a “respira antes de mandar el mensaje”.

Modo entrenamiento:

rm -i archivo.txt

Te pregunta antes de borrar.

4) Buscar archivos y texto como persona con prisa

Buscar por nombre:

find . -name "*.log"
find . -maxdepth 2 -name "Dockerfile"

Buscar texto dentro de archivos (la joya):

grep -R "DATABASE_URL" .
grep -R "TODO" src/

Más usable cuando hay mucho ruido:

grep -RIn "error" .

• -I ignora binarios
• -n muestra número de línea

Escena real: el jefe pide “cambia a producción” pero algo sigue pegándole a staging.

grep -RIn "staging" .

Eso te ahorra abrir 20 tabs y jurar que “no está en ningún lado”.

5) Pipes y redirecciones: aquí la terminal paga renta

Cuando dejas de correr comandos aislados y empiezas a armar workflows.

Filtrar una lista:

ls -la | grep "\.env"

Contar resultados (para dimensionar la talacha):

grep -R "FIXME" -n src/ | wc -l

Guardar salida a un archivo:

npm test > test-output.txt

Guardar y ver al mismo tiempo:

npm test | tee test-output.txt

Mandar errores a un archivo (cuando el script es un gritón):

python script.py 2> errors.txt

• > sobrescribe
• >> agrega al final
• 2> es stderr

6) Permisos: el día que sudo te mete en un bug

Ver permisos:

ls -la

Dar permiso de ejecución (lo mínimo necesario):

chmod +x deploy.sh

Cambiar dueño (más común en servers):

sudo chown -R ubuntu:ubuntu /var/www/app

Real talk: sudo no es varita mágica. Sí, te saca del apuro, pero si lo usas para todo terminas con archivos de root y luego nada corre sin privilegios. Si un comando pide sudo, pregúntate “¿qué estoy tocando y por qué?”.

7) Procesos y puertos: “Address already in use”

Ver procesos:

ps aux | head

Buscar por nombre:

ps aux | grep node

Ver qué está usando un puerto (clásico 3000/8080):

lsof -i :3000

Matar por PID:

kill 12345
kill -9 12345

• -9 es fuerza bruta. Úsalo cuando el proceso se pone necio.

Escena típica: levantaste Next.js, se colgó, y ya no te deja correr npm run dev.

1. lsof -i :3000
2. copias el PID
3. kill PID

8) Red y diagnóstico express (cuando “no carga”)

Probar conectividad:

ping -c 4 google.com

Ver headers (cuando el 502 te está viendo feo):

curl -I https://tu-api.com/health

Pegarle al endpoint y ver respuesta:

curl https://tu-api.com/health

Cuando backend dice “en mi máquina jala” y tú tienes un deploy tarde, curl -I te da pista sin abrir Postman ni inventar teorías.

9) SSH: entrar a un servidor sin drama

Entrar:

ssh usuario@ip-o-dominio

Con llave:

ssh -i ~/.ssh/id_rsa usuario@ip-o-dominio

Copiar con scp:

scp archivo.log usuario@servidor:/tmp/
scp usuario@servidor:/var/log/app.log ./

Momento muy real: te pasan acceso a un VPS y te dicen “nomás súbelo a producción”. No hay panel bonito, no hay wizard. Con ssh, tail y cabeza fría, lo sacas.

10) Logs que sí sirven: tail como compa

Ver el final:

tail -n 200 app.log

Seguir en vivo:

tail -f app.log

Filtrar mientras corre:

tail -f app.log | grep -i "error"

Esto es oro cuando estás en incident mode y alguien pregunta “¿qué está pasando ahorita mismo?”.

Screenshots sugeridos

• Terminal con pwd, ls -la y estructura típica de proyecto (.env.example, src/, package.json).
• grep -RIn "DATABASE_URL" . con resultados reales.
• lsof -i :3000 mostrando PID + kill PID.
• tail -f app.log | grep -i error durante un request.

Errores comunes + cómo salir sin pánico

“Permission denied” al correr un script

Causa típica: no es ejecutable.

chmod +x deploy.sh
./deploy.sh

Si el script necesita escribir en una ruta protegida, revisa ownership antes de aventar sudo como curita.

“No such file or directory” pero juras que sí existe

Causa típica: estás parado en otra carpeta.

pwd
ls

Ojo con mayúsculas/minúsculas: en Linux sí importa.

Usar rm -r en el lugar equivocado

Síntoma: se fue media carpeta y te quedas helado.
Prevención:

• pwd antes
• ls antes
• mientras agarras callo, rm -i

Si ya pasó: Git te rescata si estaba versionado.

git status
git restore .

grep no encuentra nada y tú sabes que existe

Causa típica: el texto no es igual (db_url vs DATABASE_URL) o está en otro folder.
Solución:

grep -RIn "database" .

Tip: usa -i si no quieres pelearte con mayúsculas.

Matar el proceso equivocado

Causa típica: copiaste mal el PID o había varios.
Solución: valida antes.

lsof -i :3000
ps aux | grep node

Y si es un server compartido: confirma que ese proceso es tuyo. No quieres tumbarle el deploy a otra banda.

Checklist final

• Uso pwd, ls -la, cd sin perderme.
• Creo archivos/carpetas con touch y mkdir -p.
• Copio y muevo con cp/mv sin romper rutas.
• Busco texto con grep -RIn y archivos con find.
• Entiendo |, >, >>, tee para armar pipelines.
• Reviso puertos con lsof -i :PORT y sé kill PID.
• Entro por ssh y leo logs con tail -f.

FAQ

1) ¿Tengo que memorizar todos los comandos?

No. Memoriza el core (moverte, buscar, ver logs, procesos) y aprende a leer el --help. La memoria llega con repetición y con presión de producción, para bien o para mal.

2) ¿Qué shell uso: bash o zsh?

En macOS moderno casi siempre es zsh. Para estos comandos base da igual. Lo que te conviene dominar son los conceptos: paths, permisos, pipes.

3) En Windows, ¿PowerShell o WSL?

Si vas por web/backend/devops, WSL te deja seguir la mayoría de tutoriales tal cual. PowerShell está potente, pero es otro set de comandos y otro workflow.

4) ¿sudo es malo?

No. Lo malo es usarlo sin entender. Si todo requiere sudo, probablemente traes un tema de permisos/ownership o estás escribiendo donde no deberías.

5) ¿Qué sigue después?

Git en terminal (status, diff, restore, switch) y un editor para emergencias (nano o vim). El día que estés en un server sin VS Code, lo vas a agradecer.

Siguiente episodio

Sales de la terminal con menos raspones y te metes a la vida real del dev: Git sin pánico. Tu primer merge conflict no es fracaso: es parte del proceso… y del primer pull request que sí pasa revisión.