MiniSH

TL;DR

Después de cursar Fundamentos de Sistemas Operativos, quise dejar de “entender en papel” y pasar a “entender en código”. Este proyecto nace de esa necesidad: construir una mini shell en C para ver, en la práctica, cómo funcionan procesos, pipes, redirecciones, señales y memoria dinámica.

No intenté clonar Bash. Intenté algo más útil para aprender: un sistema pequeño, legible y con límites claros.

El origen: cuando la teoría se queda corta

Hay una escena muy concreta que me empujó a hacer esto.

En clase hablábamos de fork(), de tablas de procesos, de descriptores de archivo y de execve(). Todo tenía sentido conceptual. Podía responder preguntas de examen. Pero cuando me preguntaba “¿qué ocurre exactamente cuando escribo cat archivo | wc -l en una terminal?”, mi respuesta real era: “más o menos lo sé”.

Y ese “más o menos” me molestaba.

Así que me puse una meta: construir una shell mínima desde cero, en C, y obligarme a resolver de verdad lo que una shell resuelve cada vez que ejecuta un comando.

No para sacar una feature impresionante. No para vender nada. No para presumir de complejidad.

Solo por curiosidad técnica bien entendida.

La idea del proyecto en una frase

minish es una mini shell tipo POSIX para aprender, que ejecuta comandos externos, soporta pipelines/redirecciones y tiene builtins básicos.

Lo importante no es la lista de features. Lo importante es que cada feature está elegida para tocar un concepto de sistemas:

• Comandos externos -> fork + execvp
• Pipelines -> pipe + dup2 + cierre correcto de FDs
• Redirecciones -> open + dup2
• Estado del shell -> builtins ejecutados en padre cuando toca
• Control interactivo -> manejo de SIGINT

Alcance real

Qué sí hace

• Loop interactivo con prompt (minish$)
• Lectura de línea con getline
• Parseo de tokens y operadores: |, <, >, >>
• Soporte básico de comillas simples y dobles
• Validaciones de sintaxis comunes
• Ejecución de comandos externos por PATH (execvp)
• Pipelines de N comandos
• Redirecciones de entrada/salida
• Builtins: cd, pwd, echo, exit
• Manejo básico de Ctrl+C

Qué no hace

• No expansión de variables ($HOME, $?)
• No operadores &&, ||, ;, &
• No job control (jobs, fg, bg)
• No parser completo estilo Bash (escapes/quoting avanzados)
• No historial/autocompletado

Este punto me parece clave para defender el proyecto: tener límites explicitados es una decisión técnica madura, no una carencia accidental.

Arquitectura: separación por responsabilidades

La estructura está pensada para que cada módulo haga una cosa y la haga bien:

minish
├── src
│   ├── main.c        # REPL + gestión SIGINT + orquestación
│   ├── parser.c      # tokenización y construcción de pipeline_t
│   ├── executor.c    # ejecucción de comandos: fork, exec, dup2, pipes
│   ├── builtins.c    # cd, pwd, echo, exit
│   └── utils.c       # xmalloc, xrealloc, xstrdup
└── include
    └── minish.h      # tipos y contratos

Flujo end-to-end de un comando

Cuando el usuario escribe algo, el recorrido es:

1. main lee la línea con getline.
2. Si hay contenido, llama a parse_line.
3. El parser devuelve una estructura pipeline_t (o error de sintaxis).
4. execute_pipeline recorre los comandos:
   • Decide si es builtin en padre (caso simple), o
   • Crea hijos y pipes (caso general).
5. Se espera a todos los hijos con waitpid.
6. Se toma el status del último comando.
7. Se libera memoria (free_pipeline) y vuelve al prompt.

La clave de este flujo es que no hay magia: son pasos directos y trazables.

Decisiones técnicas importantes y por qué

1) Builtins de estado en el proceso padre

Decidí que, si hay un único comando y es builtin, se ejecute en el padre.

Motivo:

• cd necesita cambiar el directorio de la shell real.
• exit necesita modificar el estado global de la shell.

Si eso corre en un hijo, el efecto muere con el hijo. Es una de esas lecciones de SO que se entienden de verdad cuando lo implementas.

2) Parser simple y explícitamente limitado

No quise construir una gramática compleja en esta fase.

Preferí un parser lineal, predecible, con errores claros:

• “Comillas sin cerrar”
• “Pipe sin comando”
• “Falta archivo para redirección”
• “Redirección duplicada”

El objetivo era robustez y entendibilidad, no soporte total de sintaxis shell.

3) Memoria dinámica en estructuras de longitud variable

Una shell no sabe cuántas palabras, comandos ni pipes vendrán en una línea.

Por eso token_list_t, argv y pipeline->commands crecen con xrealloc. Y por eso existen wrappers (xmalloc, xrealloc, xstrdup) para no repetir chequeos de NULL en cada uso.

4) Manejo de señales pensado para modo interactivo

En la shell principal, SIGINT no debe matar el proceso completo. En cambio, en hijos conviene comportamiento por defecto para que comandos externos reaccionen normal a Ctrl+C.

Esa separación mejora mucho la experiencia interactiva y refleja cómo trabajan shells reales.

Qué costó más (y por qué)

Cierre de descriptores en pipelines

Este fue el clásico punto donde un detalle pequeño rompe todo:

• Cerrar demasiado pronto -> comando sin entrada/salida
• No cerrar -> bloqueos o fugas

Entender el orden correcto de dup2, close y herencia de FDs fue de lo más formativo del proyecto.

Redirecciones en builtins

Para builtins en proceso padre, hay que redirigir temporalmente y luego restaurar stdin/stdout del shell.

Si no restauras, el shell “queda torcido” para comandos siguientes.

Consistencia de códigos de salida

No basta con ejecutar: hay que devolver status coherente.

En pipelines, minish usa el status del último comando, que es lo esperable para usuario y scripting básico.

Desventajas y errores actuales de esta versión

Esta parte es importante para una defensa honesta: lo que hoy funciona bien y lo que todavía es frágil.

Un ejemplo concreto de ejecución

Comando:

1
cat salida.txt | wc -c

Qué ocurre internamente, resumido:

1. Parser crea dos command_t en un pipeline_t.
2. Executor crea un pipe.
3. Hijo 1 (cat):
   • Abre salida.txt
   • dup2(fd_archivo, STDIN_FILENO)
   • dup2(pipe_write, STDOUT_FILENO)
   • execvp("cat", ... )
4. Hijo 2 (wc -c):
   • dup2(pipe_read, STDIN_FILENO)
   • execvp("wc", ... )
5. Padre cierra extremos de pipe que no usa y espera ambos hijos.
6. Devuelve status del último (wc).

Visto así, deja de ser magia y pasa a ser mecánica de sistema.

Mini vistazo al código (fragmento real)

Este bloque sale de src/executor.c (repositorio original), dentro de execute_pipeline:

108
pid_t pid = fork();
109
if (pid < 0) {
110
    perror("fork");
111
    if (pipefd[0] != -1) {
112
        close(pipefd[0]);
113
    }
114
    if (pipefd[1] != -1) {
115
        close(pipefd[1]);
116
    }
117
    if (prev_read != -1) {
118
        close(prev_read);
119
    }
120
    for (int j = 0; j < started; ++j) {
121
        waitpid(pids[j], NULL, 0);
122
    }
123
    free(pids);
124
    return 1;
125
}
126

127
if (pid == 0) {
128
    signal(SIGINT, SIG_DFL);
129

130
    if (prev_read != -1) {
131
        if (dup2(prev_read, STDIN_FILENO) < 0) {
132
            perror("dup2");
133
            _exit(1);
134
        }
135
    }
136

137
    if (needs_pipe) {
138
        if (dup2(pipefd[1], STDOUT_FILENO) < 0) {
139
            perror("dup2");
140
            _exit(1);
141
        }
142
    }
143

144
    if (pipefd[0] != -1) {
145
        close(pipefd[0]);
146
    }
147
    if (pipefd[1] != -1) {
148
        close(pipefd[1]);
149
    }
150
    if (prev_read != -1) {
151
        close(prev_read);
152
    }
153

154
    if (apply_redirections(&pipeline->commands[i]) != 0) {
155
        _exit(1);
156
    }
157

158
    if (is_builtin(pipeline->commands[i].argv[0])) {
159
        int st = execute_builtin(shell, pipeline->commands[i].argv);
160
        _exit(st);
161
    }
162

163
    execvp(pipeline->commands[i].argv[0], pipeline->commands[i].argv);
164
    fprintf(stderr, "%s: %s\n", pipeline->commands[i].argv[0], strerror(errno));
165
    _exit(127);
166
}
167

168
pids[i] = pid;
169
started++;
170

171
if (prev_read != -1) {
172
    close(prev_read);
173
}
174
if (pipefd[1] != -1) {
175
    close(pipefd[1]);
176
}
177
prev_read = pipefd[0];

Así se ve, en código real, la parte más delicada: fork, dup2, cierre de FDs y ejecución.

Qué está pasando aquí, paso a paso:

1. fork() divide el flujo en padre e hijo. Si falla (pid < 0), el código limpia todo lo abierto hasta ese momento (extremos de pipe, prev_read), espera los hijos ya lanzados y devuelve error. Esta limpieza evita fugas y estados inconsistentes.

2. En el hijo se restaura SIGINT por defecto. signal(SIGINT, SIG_DFL) permite que el comando externo responda a Ctrl+C como en una shell real. El proceso principal de la shell puede tener otra política, pero el hijo debe comportarse “normal”.

3. dup2 conecta la tubería al comando correcto. Si existe prev_read, se duplica a STDIN_FILENO (entrada del comando actual). Si needs_pipe es verdadero, se duplica pipefd[1] a STDOUT_FILENO (salida hacia el siguiente comando). En términos prácticos: entrada desde el comando anterior y salida hacia el siguiente.

4. Después de dup2, se cierran FDs originales. Esto es clave: tras duplicar, los descriptores antiguos ya no hacen falta. Si no se cierran, puedes provocar bloqueos (porque algún extremo de escritura sigue abierto) o consumir recursos innecesariamente.

5. Se aplican redirecciones y luego se ejecuta. apply_redirections(...) puede sobrescribir stdin/stdout si hay <, > o >>. Después, si el comando es builtin se ejecuta en el hijo (caso pipeline); si no, se llama a execvp. Si execvp falla, sale con 127, que es el código típico de “comando no ejecutable/no encontrado”.

6. El padre conserva control del pipeline. Guarda el pid, cierra lo que ya no necesita y mueve prev_read al extremo de lectura del pipe recién creado. Ese patrón permite encadenar N comandos sin mezclar descriptores.

En resumen: el fragmento no solo “lanza procesos”; implementa una coreografía precisa de descriptores y señales. Si alteras el orden de estos pasos, el pipeline puede romperse aunque las llamadas al sistema sean las mismas.

Por qué este proyecto me sirvió tanto

Porque me obligó a responder preguntas que en clase podía esquivar:

• “¿Qué cambia exactamente después de fork?”
• “¿Qué hereda un hijo y qué no?”
• “¿Cuándo debo cerrar cada FD?”
• “¿Por qué cd no puede ser un ejecutable externo cualquiera?”

Y sobre todo: me obligó a depurar comportamiento real, no solo a repetir conceptos.

Lecciones técnicas que me llevo

1. Sistemas es orden de operaciones. El mismo conjunto de llamadas puede funcionar o romperse según el orden.

2. Una API clara entre módulos vale oro. Separar parser/executor/builtins hizo que el código fuese defendible y mantenible.

3. Definir alcance temprano evita caos. Decidir explícitamente lo que NO se implementa mantiene foco y calidad.

4. Errores claros son parte del producto. Un programa de sistemas sin mensajes útiles es mucho más difícil de usar y depurar.

5. La memoria dinámica no es opcional aquí. En una shell, el tamaño de casi todo es variable.

Cierre personal

La parte más valiosa de minish no es que ejecute ls o que haga pipes.

La parte valiosa es haber pasado de “lo entiendo teóricamente” a “sé exactamente qué está pasando, dónde puede romperse y por qué”.

Si este proyecto tiene una idea central, es esta: la curiosidad técnica bien enfocada convierte conceptos abstractos en intuición real.