La mejor respuesta
Gracias por A2A.
Creo que Anmol Vishwakarma ha dado una excelente descripción sobre el importa.
Solo para asegurarnos de poner las cosas en perspectiva:
- / etc / profile, ~ / .bash\_rc , y ~ / .bash\_profile, son archivos y se denominan secuencias de comandos de configuración c . Pueden contener declaraciones de variables, exportar variables, comandos a ejecutar en el inicio de sesión como verificación de correo o noticias, configuración de umask, entre otros. Las cosas típicas que hacen los usuarios son: agregar un directorio a $ PATH, exportar alguna variable, cambiar $ PS1, configurar los colores de la pantalla, agregar un mensaje de texto de saludo, etc.
- Todos esos archivos, excepto / etc / profile, están ocultos de forma predeterminada, como lo indica el punto inicial (por lo que no es bash\_profile sino en realidad .bash\_profile ).
- Cuando inicia sesión (ya sea de forma local o remota), esto se denomina shell de inicio de sesión y se trata un poco un poco diferente de la invocación de shell normal. En ese caso, el archivo / etc / profile , si está presente, se ejecuta, después de lo cual un ~ /.bash\_profile o un archivo ~ / .bashrc se ejecuta, en ese orden.
- Para un shell interactivo, es decir con el que puedes interactuar, porque el stdin y stderr del shell son ambos TTY, el archivo ~ / .bash\_profile no se ejecuta, pero el ~ / .bashrc es.
- Para un shell no interactivo, es decir, el que tiene uno o ambos stdin / stderr no es un TTY, no se ejecuta ningún script de configuración .
- En un shell de inicio de sesión, al cerrar la sesión, se ejecuta un archivo ~ / .bash\_logout , si está presente.
- Según POSIX, stderr (y no stdout ) es la secuencia que determina si un shell es interactivo. Si se redirige stderr , no es un shell interactivo, a menos que -i se especifique en la invocación de shell. stdout no tiene el mismo efecto.
Respuesta
Esa es solo mi opinión, pero si exit en el contexto de una función de shell (que sale del proceso de shell actual) era lo mismo que un return (que regresa del función actual), entonces no podría escribir código en una función de shell que salga del script actual cuando el código en el cuerpo de la función detecta una condición fatal. Piense en las llamadas al tiempo de ejecución assert() (o equivalentes) en lenguajes de programación más estructurados.
Todo lo que podría hacer en su lugar es devolver un código de error a la persona que llama.
Cierto, salir abruptamente de errores fatales definitivamente no es el mejor estilo de programación (libsvn de Subversion una vez tuvo muy mala reputación debido a esto: errores fatales detectados en el El código de la biblioteca dio como resultado que el programa que lo usaba se cerrara abruptamente, sin dar oportunidad al código de llamada para notificar al usuario o para intentar recuperarse del error).
No obstante, poder salir abruptamente cuando se detectan errores fatales es bastante práctico en el desarrollo de soluciones que funcionan en las condiciones esperadas, y la programación de shell (y por lo tanto la programación GNU Bash también) siempre ha consistido en proporcionar soluciones prácticas breves para los casos comunes, y no soluciones complejas que manejan cuidadosamente todas las especialidades posibles. l caso (hay muchas otras herramientas / lenguajes para eso, ya sea C, Tcl, Perl, Python o incluso PowerShell).
Tenga en cuenta también que la razón probable por la que alguien está usando scripts de shell Bourne en El primer lugar en lugar de usar las herramientas / lenguajes mencionados anteriormente es porque al usar el primero es bastante más fácil armar algo que realmente haga un trabajo útil que usar el segundo: una vez se asumió que los scripts de shell permitían a los usuarios usar casi la misma sintaxis y herramientas que usaban interactivamente todos los días, por lo tanto, algo con lo que ya estaban familiarizados.
Usted preguntó: El comando incorporado return en bash es para las funciones de shell, pero ¿por qué el comando salir no es suficiente para las funciones de shell?