/ proc / self es azúcar sintáctico. Es un atajo para contaminar / proc / y el resultado de la llamada al sistema getpid () (accesible en bash como la metavariable $$). Puede ser confuso, aunque, en el caso de las secuencias de comandos de shell, ya que muchas de las declaraciones invocan otros procesos, completos con los propios PID ... PID que se refieren, en la mayoría de los casos, a procesos muertos. Considerar:
root@vps01:~# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 Jan 1 01:51 0 -> /dev/pts/0
lrwx------ 1 root root 64 Jan 1 01:51 1 -> /dev/pts/0
lrwx------ 1 root root 64 Jan 1 01:51 2 -> /dev/pts/0
lr-x------ 1 root root 64 Jan 1 01:51 3 -> /proc/26562/fd
root@vps01:~# echo $$
593
'/ bin / ls' evaluará la ruta al directorio, resolviéndolo como / proc / 26563, ya que ese es el PID del proceso, el proceso / bin / ls recién creado, que lee el contenido del directorio. Pero para cuando el próximo proceso en la tubería, en el caso de la secuencia de comandos de shell, o para cuando regrese la solicitud, en el caso de un shell interactivo, la ruta ya no existe y la salida de información se refiere a un proceso inexistente.
Sin embargo, esto solo se aplica a los comandos externos (los que son archivos de programa ejecutables reales, en lugar de estar integrados en el propio shell). Por lo tanto, obtendrá resultados diferentes si, por ejemplo, utiliza el bloqueo de nombre de archivo para obtener una lista de los contenidos del directorio, en lugar de pasar el nombre de la ruta al proceso externo / bin / ls:
root@vps01:~# ls /proc/self/fd
0 1 2 3
root@vps01:~/specs# echo /proc/self/fd/*
/proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 /proc/self/fd/255 /proc/self/fd/3
En la primera línea, el shell generó un nuevo proceso, '/ bin / ls', a través del exec () syscall, pasando "/ proc / self / fd" como argv [1]. '/ bin / ls', a su vez, abrió el directorio / proc / self / fd y leyó, luego imprimió, su contenido mientras iteraba sobre ellos.
La segunda línea, sin embargo, usa glob () detrás de escena para expandir la lista de nombres de archivo; estos se pasan como una serie de cadenas para hacer eco. (Por lo general, se implementa como un comando interno, pero a menudo también hay un binario / bin / echo ... pero esa parte es realmente irrelevante, ya que echo solo trata con cadenas que nunca alimenta a ninguna llamada al sistema relacionada con los nombres de ruta).
Ahora, considere el siguiente caso:
root@vps01:~# cd /proc/self/fd
root@vps01:~# ls
0 1 2 255
Aquí, el shell, el proceso padre de / bin / ls, ha convertido un subdirectorio de / proc / self en su directorio actual . Por lo tanto, los nombres de ruta relativos se evalúan desde su perspectiva. Mi mejor conjetura es que esto está relacionado con la semántica de archivos POSIX donde puede crear múltiples enlaces duros a un archivo, incluidos los descriptores de archivos abiertos. Esta vez, / bin / ls se comporta de manera similar a echo / proc / $$ / fd / *.
/proc/self, por supuesto.