Escribía hace tiempo sobre la «filosofía Unix,» tratándome de apegarme a ésta mientras refinaba algunos scripts. Surgieron algunas dudas. Algunas ya recurrentes. Así creo conveniente ponerles un fin.

Primero, y para empezar, ¿qué es un script? Es curioso que incluso entre círculos informáticos académicos y profesionales, mucha gente realmente ignora lo que es un script. Bien, un script es un guión, en el mismo sentido que el de una obra de teatro. Un guión no es más que una guía de actuación. En el mismo sentido en que un actor representa una obra, guiándose por las líneas de su papel. Script es el término anglosajón, guión es el castellano.

Creo que para muchos ahora hará sentido el que un archivo conteniendo comandos, instrucciones y llamados a utilerías del sistema operativo se le llama guión, pues no es más que el seguimiento de unas líneas de actuación, el seguimiento a algo ya ensayado.

A estos guiones, muchos les llaman archivos por lotes (batch) lo cual está tecnológica y semánticamente correcto hasta que involucran la interacción con el usuario, punto en el que deja de ser «por lotes». Otros les llaman archivos de comandos, lo cual está bien mientras no se incluya en ellos algo que no sea un «comando» (esperar por entradas posteriores en este blog al respecto). ¿Ven ahora la importancia y razón de llamar a las cosas por su nombre y no el de otra cosa?

El paso de valores a un script, comando, programa o utilería se puede hacer de dos formas (y no, no me refiero a que si es por valor o por referencia) sino a si se hace como un argumento o como una opción. Antes de continuar con el punto, es conveniente ampliar lo siguiente.

Cuando uno declara todo aquello que un programa, procedimiento o función espera recibir, se especifican los parámetros de dicho programa, procedimiento o función. Dependiendo del lenguaje de programación, éstos pueden ser indicados para recibir valores o dónde residen dichos valores, y si algunos estos tendrán valores por defecto. Sin embargo, dependiendo del lenguaje de programación (aunque creo en general esto es más sobre la invocación del programa que sobre la invocación interna de alguno de sus funciones y subrutinas), se podrá indicar si ciertos valores se pasan debidamente calificados o si simplemente se toman por el valor posicional en su invocación.

En el caso de los scripts de shell, donde creo es más fácil de ejemplificar, uno puede invocar el script desde la linea de comando, desde otro script o mediante su llamado desde un programa (haciendo uso de los servicios del sistema operativo), pasando argumentos (que deben corresponder con los parámetros declarados) o indicando valores para ciertas «opciones» (switches). Los primeros se identifican por su presencia y yuxtaposición; los segundos por su calificación (es decir por ser identificados mediante «una etiqueta», usualmente representada en este caso por una secuencia de caracteres precedida por dos guiones, «–«, o un guión y un caracter. En ambos casos, estos valores deben ser adecuadamente identificados y validados (lo que llamamos ser «parseados»).

En el caso de Python, por ejemplo, el llamado de un procedimiento o función puede llevar la calificación del argumento, mediante una asignación al nombre del parámetro, o puede hacerse colocando los valores de los argumentos en el orden esperado. En este lenguaje, incluso, estas dos opciones pueden ser mezcladas bajo reglas precisas.

No hay una regla que nos indique cuándo algo debe ser una opción o un argumento, como tampoco si debe ser un parámetro o un valor en un flujo de entrada (aún cuando esta sea desde la línea de comando). Esto es decisión y resultado de un diseño razonado, que haga sentido con lo que se espera (como comportamiento del programa) en lo particular y en lo general con la convivencia en su entorno. Pero, y como ese razonamiento implica, sí debe hacerse un adecuado análisis de lo que se espera el programa o script consuma, y aquello que debemos indicarle para modificar esa forma de consumo o realizar alguna acción específica en el procesamiento o en la salida (la entrega de resultados). La razón, la principal motivación de esto, debe ser el poder crear componentes de software modulares; elementos que tanto puedan ser reusados o que puedan ser integrados fácilmente sin que la forma en la que son invocados sume complejidad y dificultades a esto.