Ezt írtad: "a & nohup -ot küld azzal indítja a subshell". Én meg ezt: "a *megfogalmazás* erősen messze van a valóságtól". Szóval, most történelemóra következik:
régen, még az eredeti Bourne-shell idejében, mikor egy parancsot háttérben indítottunk és nem volt átirányítás a parancssorban, akkor az (a shell) még gyönyörűen kommunikált az eredeti stdin/stdout-tal, azaz a terminállal. (Az volt a szép idő, amikor egy háttérprocessz elkapkodta az előtérben futó shell elől az inputot.) Ezért is volt nagyon fontos az átirányítás. Ha pedig az ember Ctrl-D-vel/exittel kilépett a (fő)shellből, akkor a shell *küldött* egy HUP-szignált a háttérprocessz(ek)nek. Ettől az általában megdeglett. Ha ezt az ember nem akarta, akkor kellett "nohup parancs & " formában indítani. Mőködése: a nohup parancs elindult háttérben, beállította a *saját* környezetét úgy, hogy ignorálta a HUP-szignált, majd exec-cel elindította a paraméterként megadott parancsot maga helyett. Eredménye, mivel a SIGIGN öröklődik exec-nél, a valójában futó parancs is ignorálta a HUP-ot, így képes volt tovább futni, amikor az eredeti (szülő) shell kilépett (az ugyanis hiába küldött neki megszakítást). Valamikor (én egy korai Korn-shell-re tippelek, de nem tudom) aztán lett annyi előrelépés, hogy ha "parancs &" formájú futtatás történik (nohup nélkül akár), akkor a shell maga a gyerekprocesszre beállítja ezt a SIGIGNORE-t a hup-megszakításra. Tehát nem *küldi* a shell a nohup-ot, hanem beállítja a hup-megszakításra érzéketlenséget. (Az csak hab a tortán, hogy úgy tudom, ettől függetlenül küldi azt a szerencsétlen HUP-ot exit-nél.)