Mientras intentaba descifrar algunos scripts escritos por ex empleados de mi empresa actual, en muchos de los scripts me encontré con las siguientes declaraciones que asignan variables a algunos comandos como se muestra a continuación:
CAT=cat
GREP=grep
SED=sed
Más adelante en el script, veo que han usado estas variables en lugar de los comandos habituales:
$GREP -v "^#" `dirname $0`/abcdfilename | while read line
do
<some loop operations>
done
No veo el sentido de usar esta variable en lugar de usarla grepdirectamente. Mis preguntas son:
- ¿Tiene sentido hacer grep o sed (en nuestro caso) de esta manera?
- ¿Es este el resultado de que alguien intenta escribir un guión con la intención de hacerlo más difícil de entender para otra persona?
- ¿O es esto simplemente un ejemplo de malas secuencias de comandos?
Respuesta1
Existen diferentes implementaciones para un comando estándar en un sistema. Al igual que en Solaris 10 y versiones anteriores, tiene /bin/shel antiguo shell Bourne y /usr/xpg4/bin/shun shell compatible con POSIX. O en OSX, tiene BSD sed cuando llama sedy GNU sed cuando llama gsed. Puede elegir qué implementación desea utilizar en su secuencia de comandos.
Por lo tanto, es más fácil cambiar qué implementación en su script cuando usó una variable. Cuando quieras GNU sed:
SED=gsed
Si no utiliza la variable, debe reemplazar todas las apariciones de seden su secuencia de comandos. Aunque puedes hacerlo fácilmente, se considera una mala práctica de programación.
Respuesta2
Existe un argumento para convertir casi cualquier cosa que uses repetidamente a lo largo de un script en una variable, porque entonces puedes redefinirla una vez y hacer que se extienda por el resto del script.
Se podría argumentar que básicamente se podría hacer lo mismo con una simple búsqueda/reemplazo de sed, pero muchos usuarios desconfían de la búsqueda/reemplazo, ya que no es tan difícil reemplazar accidentalmente algo que no tenía la intención de reemplazar.
De hecho, sugeriría esta mejora con respecto a su versión existente:
GREP=${GREP:-/bin/grep}
lo que significa que GREP se configurará en lo que el usuario establezca en el shell, o si NO está configurado, entonces en /bin/grep
De esta manera, un usuario puede anular 'grep' sobre la marcha.
$ export GREP=/bin/fgrep
$ ./path/to/script.sh
Respuesta3
Probablemente sea un ejemplo de optimización prematura.
¿Cuántas alternativas tiene esa máquina, ocualquierla máquina tiene parased,grep, yawk? Apostaría que el promedio universal está cerca de 1,0. Dadas dos opciones en una máquina en particular, ¿cuáles son las probabilidades de que las implementaciones difieran de modo que el script falle con la versión encontrada en PATH y funcione con la otra? Si eso sucede, ¿es más probable que la solución sea cambiar el script o la RUTA? Si cambiar el guión resulta ser la respuesta, ¿cuáles son las probabilidades de encontrar al menos una invocación degrepen lugar de$GREP? La baraja está preparada contra la necesidad de cualquier dirección indirecta y contra la necesidad de que funcione según lo previsto si alguna vez es necesario.
Yo no lucharía contra la cultura. Si hay alguna preferencia en tu tienda por$GREPo/usr/bin/grepo sologrep, probablemente lo acompañaría para llevarnos bien. De lo contrario, KISS: evite la indirección hasta que surja la necesidad.