/ proc / self è lo zucchero sintattico. È una scorciatoia per contatenare / proc / e il risultato di getpid () syscall (accessibile in bash come metavariabile $$). Può diventare confuso, tuttavia, nel caso degli script di shell, poiché molte delle dichiarazioni invocano altri processi, completi dei propri PID ... PID che si riferiscono, più spesso, a processi morti. Ritenere:
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' valuterà il percorso della directory, risolvendolo come / proc / 26563, poiché quello è il PID del processo - il processo / bin / ls appena creato - che legge il contenuto della directory. Ma quando il processo successivo nella pipeline, nel caso di script di shell, o quando ritorna il prompt, nel caso di una shell interattiva, il percorso non esiste più e l'output delle informazioni si riferisce a un processo inesistente.
Ciò si applica solo ai comandi esterni (quelli che sono file di programma eseguibili effettivi, invece di essere integrati nella shell stessa). Quindi, otterrai risultati diversi se, ad esempio, usi il globbing del nome file per ottenere un elenco dei contenuti della directory, anziché passare il nome del percorso al processo esterno / 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
Nella prima riga, la shell ha generato un nuovo processo, '/ bin / ls', tramite la syscall exec (), passando "/ proc / self / fd" come argv [1]. '/ bin / ls', a sua volta, apriva la directory / proc / self / fd e leggeva, quindi stampava, il suo contenuto mentre scorreva su di essi.
La seconda riga, tuttavia, usa glob () dietro le quinte per espandere l'elenco dei nomi dei file; questi vengono passati come una matrice di stringhe da eco. (Di solito implementato come comando interno, ma spesso c'è anche un binario / bin / echo ... ma quella parte è in realtà irrilevante, poiché l'eco ha a che fare solo con stringhe che non si alimenta mai a nessuna scala relativa ai nomi dei percorsi.)
Ora, considera il seguente caso:
root@vps01:~# cd /proc/self/fd
root@vps01:~# ls
0 1 2 255
Qui, la shell, il processo genitore di / bin / ls, ha reso una sottodirectory di / proc / self la sua directory corrente . Pertanto, i percorsi relativi vengono valutati dal suo punto di vista. La mia ipotesi migliore è che ciò sia correlato alla semantica dei file POSIX in cui è possibile creare più collegamenti fisici a un file, inclusi eventuali descrittori di file aperti. Quindi questa volta, / bin / ls si comporta in modo simile a echo / proc / $$ / fd / *.
/proc/self, ovviamente.