$ f() { echo hola ; }
$ f
hola
$ export -f f
$ bash -c "f"
hola
En el manual de bash puedes encontrar la explicación de export -f. Una pista para ver cómo funciona es ejecutar:
$ bash -c 'cat /proc/$$/environ | xargs -0 echo'
después de los comandos anteriores.
@yo Vale, pero entonces pierdo las variables que había definido ya en mi script, porque estoy ejecutándolo en un nuevo bash, ¿no?
Y terminado el script, ¿debo des-exportar la función para que desaparezca?
@microblogc si las exportas aparecen en los subshells, pero sí:
$ A=a
$ echo $A
a
$ bash -c 'echo $A'
$
Si ejecutas tu script con ./script, eso se ejecuta en un subproceso y su entorno se pierde al finalizar. Si lo ejecutas con '. script', se ejecuta en el mismo entorno en el que estás modificándolo.
Recomiendo usar '. script' sólo cuando es estrictamente necesario; precisamente por necesitar afectar al entorno o (muy raramente) por rendimiento.
@microblogc ten en cuenta que find -exec ejecuta un subproceso, con lo que pierdes igual las variables que las funciones. (Que al final son casi lo mismo.)
@yo Es que yo abuso de . script porque me permite no tener la carpeta actual en el path.
@microblogc creo que ./script debería ser más o menos equivalente, no se me ocurren casos (fuera de lo de querer afectar el entorno o no querer pagar subprocesos) en los que usar . sea una ventaja. Pero no es un tema que domine 100%
@microblogc y menos importante: antes he mencionado trap como signo de que hay que dejar bash porque si en la mayoría de lenguajes el control de errores y los bloques "finally" ya son complicados y un dolor de cabeza para hacerlos correctamente, en bash todavía más.
Intentar "deshacer" cosas en bash es... mala señal. Lo suyo es usar subprocesos para lo que sea importante limpiar y se pueda acotar mediante un subproceso. (Y eso implica pagar el coste de los subprocesos, claro.)
