>>> strano... da shell at legge l'interprete da utilizzare dal file stesso >>> mentre con l'opzione -f lo esegue con /bin/sh.
No. Il comportamento e` uguale: passare da stdin o con "-f" con cambia niente: viene salvato da qualche parte per poi essere passato a /bin/sh. Cosi` dice la documentazione, cosi` ho fatto vedere che si comporta (dire se uno script asincrono ha fallito o no non e` banale, fargli fare "ps $$ > /dev/tty" e` facile e da` risultati certi. Si veda il mio messaggio. > Comunque sia che si lanci lo script da shell at, con il comando at -f, > direttamente da shell sh o con il comando sh -c, viene utilizzata sempre > la stessa shell /bin/sh Se faccio "sh -c" ovviamente parte sh. Se faccio "bash -c" parte bash. > Probabilmente chiamare at con il parametro -f [...] Ragazzi, e` tutto *molto* piu` facile. "at" e` vecchio, e come tale usa /bin/sh come interprete. Probabilmente niente, e` cosi` e basta. Ricordiamo che le cose fatte bene sono facili, senza casi speciali. "-f" non e` un caso speciale, e` *come* dare da stdin. > [...] fara` direttamente una chiamata execve (che non so cosa sia ma > riporto quel che hai scritto tu) al kernel che mi sembra di aver > capito non va a leggere la shebang dello script... Invece e` proprio l'opposto. Se un eseguibile e` eseguibile, viene eseguito (che sia python o che, se ha il suo #! o altri trucchi a posto, dopo "chmod +x" e` eseguibile ed esegue). Se invece qualcuno dichiara di volere un testo da passare a /bin/sh, lo passa a /bin/sh. E "#!/bin/basta" e` un commento, come e` giusto che sia. > quindi non si potranno nemmeno chiamare script in altri > linguaggi (php, python etc...). Tutto cio` che e` eseguibile puo` essere eseguito da /bin/sh. E` semplice e lineare. Non inventiamo complicazioni che non ci sono. saluti /alessandro
