Lo que realmente ocurre es que fiesta mantiene el archivo abierto y rm
no hará que esa parada.
Entonces rm
llama a la función libc "unlink()" que eliminará el "enlace" al inodo del directorio en el que se encuentra. Este "enlace" es de hecho un nombre de archivo junto con un número inodo (puede ver el inode números con ls -i
).
El inodo existe mientras los programas lo tengan abierto.
Usted puede probar fácilmente esta demanda de la siguiente manera:
$ echo read a> ni
$ bash ni
mientras que en otra ventana:
$ pgrep -lf bash\ ni
31662 bash ni
$ lsof -p 31662|grep ni
bash 31662 wmertens 255r REG 14,2 7 12074052 /Users/wmertens/ni
$ rm ni
$ lsof -p 31662|grep ni
bash 31662 wmertens 255r REG 14,2 7 12074052 /Users/wmertens/ni
El archivo todavía está abierta a pesar de que ya no se puede ver en ls. Así que no es que bash leyó todo el archivo, simplemente no se ha ido hasta que Bash termina con eso.
Cuando se ejecuta una aplicación, su código se carga en la memoria. Solo está eliminando el archivo en el disco, lo que no afecta el código en la memoria. –
Es de suponer que toda la secuencia de comandos se lee en la memoria en la ejecución y, por lo tanto, los comandos posteriores a 'rm test.sh' aún existen en la memoria para su ejecución. – MrMisterMan
No hace una copia en la memoria. Entonces, por ejemplo, si el script se modifica mientras se está ejecutando, ejecutará las modificaciones. Esto me ha estado dando dolores de cabeza recientemente. Lindo ejemplo: este script de una línea llenará tu disco en poco tiempo: 'cat $ 0 >> $ 0'. – Ned