it-swarm-es.tech

Patrones de diseño o mejores prácticas para scripts de Shell

¿Alguien sabe de recursos que hablen sobre mejores prácticas o patrones de diseño para scripts de Shell (sh, bash, etc.)?

160
user14437

Escribí scripts de Shell bastante complejos y mi primera sugerencia es "no". La razón es que es bastante fácil cometer un pequeño error que dificulta su secuencia de comandos, o incluso hacerlo peligroso.

Dicho esto, no tengo otros recursos para aprobarte, sino mi experiencia personal. Esto es lo que normalmente hago, que es excesivo, pero tiende a ser sólido, aunque muy verboso.

Invocación

haz que tu script acepte opciones largas y cortas. tenga cuidado porque hay dos comandos para analizar las opciones, getopt y getopts. Usa getopt cuando tengas menos problemas.

CommandLineOptions__config_file=""
CommandLineOptions__debug_level=""

getopt_results=`getopt -s bash -o c:d:: --long config_file:,debug_level:: -- "[email protected]"`

if test $? != 0
then
    echo "unrecognized option"
    exit 1
fi

eval set -- "$getopt_results"

while true
do
    case "$1" in
        --config_file)
            CommandLineOptions__config_file="$2";
            shift 2;
            ;;
        --debug_level)
            CommandLineOptions__debug_level="$2";
            shift 2;
            ;;
        --)
            shift
            break
            ;;
        *)
            echo "$0: unparseable option $1"
            EXCEPTION=$Main__ParameterException
            EXCEPTION_MSG="unparseable option $1"
            exit 1
            ;;
    esac
done

if test "x$CommandLineOptions__config_file" == "x"
then
    echo "$0: missing config_file parameter"
    EXCEPTION=$Main__ParameterException
    EXCEPTION_MSG="missing config_file parameter"
    exit 1
fi

Otro punto importante es que un programa siempre debe devolver cero si se completa con éxito, no cero si algo salió mal.

Llamadas de función

Puede llamar a funciones en bash, solo recuerde definirlas antes de la llamada. Las funciones son como scripts, solo pueden devolver valores numéricos. Esto significa que tienes que inventar una estrategia diferente para devolver valores de cadena. Mi estrategia es usar una variable llamada RESULTADO para almacenar el resultado y devolver 0 si la función se completó limpiamente. Además, puede generar excepciones si está devolviendo un valor diferente de cero, y luego establecer dos "variables de excepción" (mía: EXCEPTION y EXCEPTION_MSG), la primera con el tipo de excepción y la segunda con un mensaje legible.

Cuando llama a una función, los parámetros de la función se asignan a los vars especiales $ 0, $ 1, etc. Le sugiero que los coloque en nombres más significativos. Declarar las variables dentro de la función como local:

function foo {
   local bar="$0"
}

Situaciones propensas a errores

En bash, a menos que declare lo contrario, una variable no establecida se usa como una cadena vacía. Esto es muy peligroso en caso de error tipográfico, ya que la variable mal escrita no se informará y se evaluará como vacía. utilizar

set -o nounset

para evitar que esto suceda. Sin embargo, tenga cuidado, porque si lo hace, el programa abortará cada vez que evalúe una variable no definida. Por este motivo, la única forma de verificar si una variable no está definida es la siguiente:

if test "x${foo:-notset}" == "xnotset"
then
    echo "foo not set"
fi

Puede declarar variables como de solo lectura:

readonly readonly_var="foo"

Modularización

Puede lograr la modularización "tipo Python" si utiliza el siguiente código:

set -o nounset
function getScriptAbsoluteDir {
    # @description used to get the script path
    # @param $1 the script $0 parameter
    local script_invoke_path="$1"
    local cwd=`pwd`

    # absolute path ? if so, the first character is a /
    if test "x${script_invoke_path:0:1}" = 'x/'
    then
        RESULT=`dirname "$script_invoke_path"`
    else
        RESULT=`dirname "$cwd/$script_invoke_path"`
    fi
}

script_invoke_path="$0"
script_name=`basename "$0"`
getScriptAbsoluteDir "$script_invoke_path"
script_absolute_dir=$RESULT

function import() { 
    # @description importer routine to get external functionality.
    # @description the first location searched is the script directory.
    # @description if not found, search the module in the paths contained in $Shell_LIBRARY_PATH environment variable
    # @param $1 the .shinc file to import, without .shinc extension
    module=$1

    if test "x$module" == "x"
    then
        echo "$script_name : Unable to import unspecified module. Dying."
        exit 1
    fi

    if test "x${script_absolute_dir:-notset}" == "xnotset"
    then
        echo "$script_name : Undefined script absolute dir. Did you remove getScriptAbsoluteDir? Dying."
        exit 1
    fi

    if test "x$script_absolute_dir" == "x"
    then
        echo "$script_name : empty script path. Dying."
        exit 1
    fi

    if test -e "$script_absolute_dir/$module.shinc"
    then
        # import from script directory
        . "$script_absolute_dir/$module.shinc"
    Elif test "x${Shell_LIBRARY_PATH:-notset}" != "xnotset"
    then
        # import from the Shell script library path
        # save the separator and use the ':' instead
        local saved_IFS="$IFS"
        IFS=':'
        for path in $Shell_LIBRARY_PATH
        do
            if test -e "$path/$module.shinc"
            then
                . "$path/$module.shinc"
                return
            fi
        done
        # restore the standard separator
        IFS="$saved_IFS"
    fi
    echo "$script_name : Unable to find module $module."
    exit 1
} 

luego puede importar archivos con la extensión .shinc con la siguiente sintaxis

importar "AModule/ModuleFile"

Que se buscarán en Shell_LIBRARY_PATH. Como siempre importa en el espacio de nombres global, recuerde prefijar todas sus funciones y variables con un prefijo adecuado, de lo contrario, corre el riesgo de choques de nombres. Yo uso doble guión bajo como el punto de python.

Además, pon esto como primera cosa en tu módulo.

# avoid double inclusion
if test "${BashInclude__imported+defined}" == "defined"
then
    return 0
fi
BashInclude__imported=1

Programación orientada a objetos

En bash, no puedes hacer programación orientada a objetos, a menos que construyas un sistema de asignación de objetos bastante complejo (pensé en eso. Es factible, pero insano). En la práctica, sin embargo, puede hacer "Programación orientada a Singleton": tiene una instancia de cada objeto y solo una.

Lo que hago es: defino un objeto en un módulo (vea la entrada de modularización). Luego defino vars vacíos (análogos a las variables miembro) una función init (constructor) y funciones miembro, como en este código de ejemplo

# avoid double inclusion
if test "${Table__imported+defined}" == "defined"
then
    return 0
fi
Table__imported=1

readonly Table__NoException=""
readonly Table__ParameterException="Table__ParameterException"
readonly Table__MySqlException="Table__MySqlException"
readonly Table__NotInitializedException="Table__NotInitializedException"
readonly Table__AlreadyInitializedException="Table__AlreadyInitializedException"

# an example for module enum constants, used in the mysql table, in this case
readonly Table__GENDER_MALE="GENDER_MALE"
readonly Table__GENDER_FEMALE="GENDER_FEMALE"

# private: prefixed with p_ (a bash variable cannot start with _)
p_Table__mysql_exec="" # will contain the executed mysql command 

p_Table__initialized=0

function Table__init {
    # @description init the module with the database parameters
    # @param $1 the mysql config file
    # @exception Table__NoException, Table__ParameterException

    EXCEPTION=""
    EXCEPTION_MSG=""
    EXCEPTION_FUNC=""
    RESULT=""

    if test $p_Table__initialized -ne 0
    then
        EXCEPTION=$Table__AlreadyInitializedException   
        EXCEPTION_MSG="module already initialized"
        EXCEPTION_FUNC="$FUNCNAME"
        return 1
    fi


    local config_file="$1"

      # yes, I am aware that I could put default parameters and other niceties, but I am lazy today
      if test "x$config_file" = "x"; then
          EXCEPTION=$Table__ParameterException
          EXCEPTION_MSG="missing parameter config file"
          EXCEPTION_FUNC="$FUNCNAME"
          return 1
      fi


    p_Table__mysql_exec="mysql --defaults-file=$config_file --silent --skip-column-names -e "

    # mark the module as initialized
    p_Table__initialized=1

    EXCEPTION=$Table__NoException
    EXCEPTION_MSG=""
    EXCEPTION_FUNC=""
    return 0

}

function Table__getName() {
    # @description gets the name of the person 
    # @param $1 the row identifier
    # @result the name

    EXCEPTION=""
    EXCEPTION_MSG=""
    EXCEPTION_FUNC=""
    RESULT=""

    if test $p_Table__initialized -eq 0
    then
        EXCEPTION=$Table__NotInitializedException
        EXCEPTION_MSG="module not initialized"
        EXCEPTION_FUNC="$FUNCNAME"
        return 1
    fi

    id=$1

      if test "x$id" = "x"; then
          EXCEPTION=$Table__ParameterException
          EXCEPTION_MSG="missing parameter identifier"
          EXCEPTION_FUNC="$FUNCNAME"
          return 1
      fi

    local name=`$p_Table__mysql_exec "SELECT name FROM table WHERE id = '$id'"`
      if test $? != 0 ; then
        EXCEPTION=$Table__MySqlException
        EXCEPTION_MSG="unable to perform select"
        EXCEPTION_FUNC="$FUNCNAME"
        return 1
      fi

    RESULT=$name
    EXCEPTION=$Table__NoException
    EXCEPTION_MSG=""
    EXCEPTION_FUNC=""
    return 0
}

Señales de captura y manejo

Encontré esto útil para atrapar y manejar excepciones.

function Main__interruptHandler() {
    # @description signal handler for SIGINT
    echo "SIGINT caught"
    exit
} 
function Main__terminationHandler() { 
    # @description signal handler for SIGTERM
    echo "SIGTERM caught"
    exit
} 
function Main__exitHandler() { 
    # @description signal handler for end of the program (clean or unclean). 
    # probably redundant call, we already call the cleanup in main.
    exit
} 

trap Main__interruptHandler INT
trap Main__terminationHandler TERM
trap Main__exitHandler EXIT

function Main__main() {
    # body
}

# catch signals and exit
trap exit INT TERM EXIT

Main__main "[email protected]"

Consejos

Si algo no funciona por algún motivo, intente reordenar el código. El orden es importante y no siempre intuitivo.

ni siquiera consideres trabajar con tcsh. No soporta funciones, y es horrible en general.

Espero que ayude, aunque por favor tenga en cuenta. Si tiene que usar el tipo de cosas que escribí aquí, significa que su problema es demasiado complejo para ser resuelto con Shell. usa otro idioma Tuve que usarlo debido a factores humanos y legado.

211
Stefano Borini

Eche un vistazo a Advanced Bash-Scripting Guide para obtener mucha información sobre los scripts de Shell, y no solo Bash.

No escuches a las personas que te dicen que veas otros idiomas, posiblemente más complejos. Si Shell scripting satisface sus necesidades, use eso. Quieres funcionalidad, no fantasía. Los nuevos idiomas proporcionan nuevas habilidades valiosas para su currículum, pero eso no ayuda si tiene trabajo que debe hacerse y ya conoce a Shell.

Como se indicó, no hay muchas "mejores prácticas" o "patrones de diseño" para los scripts de Shell. Los diferentes usos tienen diferentes pautas y sesgos, como cualquier otro lenguaje de programación.

23
jtimberman

Shell script es un lenguaje diseñado para manipular archivos y procesos. Si bien es genial para eso, no es un lenguaje de propósito general, así que siempre trate de pegar la lógica de las utilidades existentes en lugar de recrear una nueva lógica en el script de Shell.

Aparte de ese principio general, he recopilado algunos errores comunes en el script de Shell .

19
pixelbeat

Hubo una gran sesión en OSCON este año (2008) sobre este tema: http://assets.en.oreilly.com/1/event/12/Shell%20Scripting%20Craftsmanship%20Presentation%201.pdf

12
Fhoxh

Fácil: usa Python en lugar de scripts de Shell. Obtiene un aumento de casi 100 veces en la capacidad de lectura, sin tener que complicar nada que no necesite, y conservando la capacidad de convertir partes de su script en funciones, objetos, objetos persistentes (zodb), objetos distribuidos (pyro) casi sin ningún código extra.

8
Joao S O Bueno

Saber cuándo usarlo. Para los comandos de pegado rápido y sucio juntos está bien. Si necesita tomar más de unas pocas decisiones no triviales, bucles, cualquier cosa, elija Python, Perl y modularize .

El mayor problema con Shell a menudo es que el resultado final se parece a una gran bola de barro, 4000 líneas de bash y crecimiento ... y no puedes deshacerte de ella porque ahora todo tu proyecto depende de ello. Por supuesto, comenzó en 40 líneas de hermosa fiesta.

8
Paweł Hajdan

use set -e para no arar hacia adelante después de los errores. Intenta que sea compatible sin basarse en bash si quieres que se ejecute en no Linux.

8
user10392

Para encontrar algunas de las "mejores prácticas", observe cómo las distribuciones de Linux (por ejemplo, Debian) escriben sus guiones de inicio (que generalmente se encuentran en /etc/init.d)

La mayoría de ellos no tienen "bash-isms" y tienen una buena separación de ajustes de configuración, archivos de biblioteca y formato de origen.

Mi estilo personal es escribir un master-shellscript que defina algunas variables predeterminadas y luego intente cargar ("fuente") un archivo de configuración que pueda contener nuevos valores.

Intento evitar las funciones, ya que tienden a hacer que el script sea más complicado. (Perl fue creado para ese propósito.)

Para asegurarse de que el script sea portátil, pruebe no solo con #!/Bin/sh, sino que también use #!/Bin/ash, #!/Bin/dash, etc. Pronto detectará el código específico de Bash.

7
Willem