El sentido de Unix y de ls

En los últimos días han aparecido dos artículos afirmando que Unix no sigue la filosofía Unix, recurriendo como ejemplo al montón de opciones de ls.

La repercusión de esos artículos me ha sorprendido y confirmado. Que Unix no es perfecto ni sigue sus propios principios no debería ser a estas alturas sorpresa para nadie, Plan 9 es la confirmación práctica de ello. El mundo Unix padece del mito de la perfección y de la Pureza De Los Principios, y pocos están dispuestos a vivir con el hecho de que usamos derivados de Unix sólo por costumbre y compatibilidad, que instalamos en nuestras máquinas de última generación sistemas operativos con defectos bastante sonrojantes y que podríamos tener cosas mejores si pudiéramos partir de cero.

Pero quería referirme a la extraña tendencia a poner como ejemplo de usurpación de principios a ls y sus numerosas opciones. En realidad, se suele acusar de "bloat" no sólo a ls, sino de todas las utilidades Unix básicas de GNU. Se acusa a estas utilidades de faltar al principio de un programa que hace una sola función y la hace bien, y su resultado es una salida de texto que puede ser procesada con otros comandos mediante tuberías. ls sería en cambio un programa que hace muchas cosas y no siempre bien, y por tanto un comando "antiunix". A mi, esta acusación me parece errónea por varios motivos.

En primer lugar hay que dejar bien claro -aunque no tenga mucho que ver con ls- que si Unix tiene comandos simples para combinarlos mediante tuberías, es precisamente para eso: para combinar, para construir cosas. El propósito de un sistema Unix no es evitar la creación de programas grandes, complejos y con muchas opciones, sino precisamente facilitar su creación. Esos programas no son contrarios al espíritu Unix, son bienvenidos y no desentonan.

Pero sobre todo, el entorno de programación de Unix no es la solución a todo, de hecho a menudo es un entorno pobre (programar scripts complejos en bash es una proeza que debería tenerse en cuenta en el Purgatorio). En el Unix original, construir lineas de comando simples comunicadas con tuberías no sólo eran la manera recomendada de construir programas complejos, sino que era la única manera: Unix en sus inicios no soportaba aspectos tan elementales hoy en día como librerías compartidas. Parte de la funcionalidad de las Xlib de X11 se programó en el servidor porque las librerías compartidas no se había popularizado y los "demonios" eran la manera habitual de compartir código entre clientes.

En el caso de ls y sus numerosísimas opciones, está claro que hay algunas que podrían ser eliminadas y sustituidas por una combinación de shell que procese la salida de un ls más simple. Por ejemplo, la opción -i, que muestra el número de inodo, podría ser eliminada y sustituida por una combinación de comandos que extraigan cada nombre de archivo de la salida de ls, se lo pasen al comando stat, extraigan de stat el número de inodo, e impriman en la pantalla la salida equivalente de ls -i. Sin embargo, lo cierto es que semejante combinación es más compleja, y probablemente también menos eficiente (por los stat()s extra), que su equivalente en ls.c.

Por último, si a pesar de esto a la gente le parece que el ls actual es excesivamente complejo, la propia extensibilidad de Unix permite a uno programarse su ls ideal y utilizarlo en sus scripts (aunque nadie lo hará, porque no merece la pena). En realidad, parte de todo este dilema de ls es que el comando ls es un bloque constructor básico de comandos Unix y simultaneamente es utilizado como programa orientado al "usuario" (del shell): lo "ideal" para algunos sería, supongo, que estas dos funcionalidades estuvieran en dos comandos diferentes y que el último fuese implementado procesando la salida del primero. Lo cierto es que sería una pérdida de tiempo. Aunque Unix tenga sus más y sus menos, que ls tenga muchas opciones es, en mi opinión, el menor de sus problemas.