El comando llevaba una tubería y la tabla de Markdown se partió justo ahí

Lucía mantiene los runbooks de guardia de su equipo. Son ficheros Markdown con tablas de tres columnas: «síntoma», «comando» y «qué mirar». Una tarde decidió montar en el IDE del navegador una vista previa de esas tablas, para revisarlas antes de subirlas al repositorio. Parsear una tabla de Markdown parece cosa de diez líneas: partes cada fila por las barras verticales, recortas espacios y pintas las celdas.

Funcionó con todas las tablas menos una. La fila de «el proceso no responde» llevaba en la columna del comando ps aux | grep node, entre comillas invertidas. La vista previa sacó cuatro celdas, aunque la cabecera tenía tres, y la descripción acabó en una columna que no existía.

El arreglo obvio era el equivocado

Pegó la función y la tabla real, tal cual, en el chat de Elffuss Code. La primera propuesta fue la que se le ocurriría a cualquiera: no partir por las barras que estén dentro de un bloque de código. Lucía la aplicó y la vista previa quedó perfecta. Pero al subir el fichero, GitHub pintó la fila rota igual que antes.

Volvió a preguntar, y esta vez pidió que se ciñera a la especificación de GitHub Flavored Markdown y no a lo que «tendría sentido». Ahí salió el detalle. En GFM, las filas se dividen en celdas antes de interpretar el código en línea, así que una barra entre comillas invertidas también corta. La única forma de meter una barra en una celda es escaparla con \|, también dentro del código. Además, si una fila trae más celdas que la cabecera, lo que sobra se descarta sin avisar. En GitHub, media orden desaparecía.

Es decir, su primer arreglo dejaba la vista previa peor que inútil: enseñaba una tabla bonita que no se parecía a la publicada.

Lo que quedó

• La fila se corta en cada barra sin escapar, esté donde esté, como manda GFM.
• Al pintar la celda, las barras escapadas se muestran como barras normales, también las que van dentro del código.
• Si una fila tiene más celdas que la cabecera, la vista previa la marca en rojo y dice cuántas se van a perder. Si tiene menos, avisa de que GitHub las rellenará vacías.

Con el aviso puesto, repasó el resto de runbooks y encontró dos tablas más con el mismo problema. Una tenía un awk que llevaba meses publicado a medias sin que nadie lo notara.

Por qué en local

Lo que Lucía pegó en el chat no era un ejemplo inventado. Eran los runbooks de verdad, con nombres de máquinas internas, ubicaciones de logs y algún comando de recuperación que no querría ver en el historial de un servicio ajeno. Como el modelo corre en su navegador, sobre su propia GPU, pudo pegar las tablas enteras sin recortarlas ni disfrazarlas. Y eso es justo lo que hizo falta para que apareciera el caso raro. Si hubiera tenido que limpiar el texto antes de preguntar, probablemente habría quitado la fila que fallaba.

Una vista previa no está para que la tabla se vea bien. Está para que se vea igual que lo que vas a publicar.