Cómo definir una secuencia de comandos de shell para que no se ejecute

Estoy definiendo un script de shell que un usuario debería en sourcelugar de ejecutar.

¿Existe una forma convencional o inteligente de indicarle al usuario que este es el caso, por ejemplo a través de una extensión de archivo?

¿Hay algún código de shell que pueda escribir en el archivo mismo, lo que hará que repita un mensaje y se cierre si se ejecuta en lugar de obtenerlo, de modo que pueda ayudar al usuario a evitar este error obvio?

Suponiendo que está ejecutando bash, coloque el siguiente código cerca del inicio del script que desea que se obtenga pero no se ejecute:

if [ "${BASH_SOURCE[0]}" -ef "$0" ]
then
    echo "Hey, you should source this script, not execute it!"
    exit 1
fi

En bash, ${BASH_SOURCE[0]}contendrá el nombre del archivo actual que el shell está leyendo independientemente de si se está obteniendo o ejecutando.

Por el contrario, $0es el nombre del archivo actual que se está ejecutando.

-efprueba si estos dos archivos son el mismo archivo. Si es así, alertamos al usuario y salimos.

Ni -eftampoco BASH_SOURCEson POSIX. Si bien -efes compatible con ksh, yash, zsh y Dash, BASH_SOURCErequiere bash. Enzsh , sin embargo, ${BASH_SOURCE[0]}podría ser reemplazado por ${(%):-%N}.

Un archivo no ejecutable puede obtenerse pero no ejecutarse, por lo que, como primera línea de defensa, no establecer el indicador ejecutable debería ser una buena pista ...

Editar: truco con el que me topé: hacer que el shebang sea cualquier ejecutable que no sea un intérprete de shell, /bin/falsehace que el script devuelva un error (rc! = 0)

#!/bin/false "This script should be sourced in a shell, not executed directly"

Hay varios métodos sugeridos en esta publicación de Stack Overflow , de los cuales, me gustó el basado en funciones sugerido por Wirawan Purwanto y mr.spuratic mejor:

La forma más sólida, como lo sugiere Wirawan Purwanto, es verificar FUNCNAME[1] dentro de una función :

function mycheck() { declare -p FUNCNAME; }
mycheck

Luego:

$ bash sourcetest.sh
declare -a FUNCNAME='([0]="mycheck" [1]="main")'
$ . sourcetest.sh
declare -a FUNCNAME='([0]="mycheck" [1]="source")'

Esto es equivalente a verificar la salida de callerlos valores mainy sourcedistinguir el contexto del llamante. El uso le FUNCNAME[]ahorra capturar y analizar callerresultados. Sin embargo, debe saber o calcular la profundidad de su llamada local para ser correcta. Casos como un script que se obtiene de otra función o script harán que la matriz (pila) sea más profunda. ( FUNCNAMEes una variable de matriz de bash especial, debe tener índices contiguos correspondientes a la pila de llamadas, siempre que nunca sea así unset).

Para que pueda agregar al inicio del script:

function check()
{
    if [[ ${FUNCNAME[-1]} != "source" ]]   # bash 4.2+, use ${FUNCNAME[@]: -1} for older
    then
        printf "Usage: source %s\n" "$0"
        exit 1
    fi
}
check

Asumiendo que es inútil, en lugar de perjudicial, ejecutar el script, puede agregar

return 0 || printf 'Must be sourced, not executed\n' >&2

hasta el final del guión. returnfuera de una función tiene un código de salida distinto de cero a menos que el archivo se obtenga.

Cuando obtiene un script de shell, se ignora la línea shebang . Al colocar un shebang no válido, puede alertar al usuario de que el script se ejecutó erróneamente:

#!/bin/bash source-this-script
# ...

El mensaje de error será este:

/bin/bash: source-this-script: No such file or directory

El nombre del argumento (arbitrario) ya proporciona una pista fuerte, pero el mensaje de error aún no es 100% claro. Podemos arreglar esto con un script de utilidad source-this-scriptque se coloca en algún lugar de su PATH:

#!/bin/sh
echo >&2 "This script must be sourced, not executed${1:+: }${1:-!}"
exit 1

Ahora, el mensaje de error será este:

This script must be sourced, not executed: path/to/script.sh

Comparación con otros enfoques

En comparación con las otras respuestas, este enfoque solo requiere cambios mínimos en cada script (y tener una línea shebang ayuda con la detección del tipo de archivo en los editores y especifica el dialecto del script de shell, por lo que incluso hay beneficios). La desventaja es un mensaje de error algo poco claro, o la adición (única) de otro script de shell.

Sin embargo, no evita la invocación explícita a través de bash path/to/script.sh(¡gracias @muru!).