Merci Perderabo. Mais que faire si je ne donne cette déclaration appelle les numéros de magie dans ma coquille ...

Quelque chose de mal en elle .. il semble que presque un codage standard pour le script que nous écrire ...

Merci,
Nisha

Si vous quittez-la, puis la coque échoue quand il essaie de exec () il. Quelle est la prochaine étape dépend du shell que vous utilisez votre login shell. La plupart des obus supposons que le scénario est écrit dans leur propre langue. Donc, si vous utilisez bash comme shell de login et essayez d'exécuter un script shell Korn qui n'ont pas la ligne #! / usr / bin / ksh, bash puis va essayer de l'exécuter comme un script bash. bash et ksh sont peu compatibles, ce qui pourrait fonctionner. D'autre part, il peut échouer.

Supposons que vous utilisez pour vous connecter ksh shell et que vous exécutez korn shell scripts sans que cette première ligne. Les choses semblent ok. Ensuite, vous décidez d'essayer bash comme shell de login. Soudain, les choses pause.

Et les choses seront particulièrement sombre pour quiconque utilise csh / tcsh comme leur connexion et exécute des scripts shell, sans que la première ligne. Ces obus inspecter le script d'essayer de deviner si elles ou de l'ancien bourne shell devrait exécuter. Le test qu'ils utilisent est tellement mauvaise qu'elle peut être battue par un générateur de nombres aléatoires. Et nul utilise encore le vieux bourne shell de toute façon.

Et oui, il est une sorte de standard. La plupart des noyaux savoir. Mais je ne crois pas que c'est un fonctionnaire posix standard.

Merci Perderabo ..

Cela efface mes doutes ...

Merci,
Nisha

Aussi, à partir de la USENET Unix FAQS, Voir Pourquoi certains scripts commençant par #! ... ?
Et voir cette page et faire défiler vers le bas à la section RAISON près de la fin de l'information sur un trait d'union mobile sur cette ligne.