Pentru portabilitate, puteți presupune în siguranță că #!/bin/sh va găsi un shell care este în mare parte compatibil POSIX pe orice sistem standard Unix sau Linux, dar asta este cu adevărat.
În FreeBSD, OpenBSD și NetBSD ( împreună cu DragonFly, PC-BSD și alte derivate), bash se află la /usr/local/bin/bash (dacă este instalat), deci /usr/bin/env abordarea oferă portabilitate între Linux și BSD.
Android nu este un sistem standard Unix sau Linux. Pe telefonul meu Android care nu are rădăcină, niciunul dintre /usr/bin/env, /bin/bash o r chiar există /bin/sh și shell-ul sistemului este /system/bin/sh.
Un script shell care lipsește #! (shebang) va încerca să ruleze în shell-ul care l-a apelat pe unele sisteme sau poate folosi un interpret implicit diferit (/bin/bash de exemplu) , pe alte sisteme. Și, deși acest lucru poate funcționa în Android, nu este garantat să funcționeze în alte sisteme de operare, unde utilizatorii pot alege să utilizeze un shell interactiv care nu este bash. (Folosesc tcsh în FreeBSD, unde este shell-ul implicit, iar scriptul fără shebang sunt interpretate de shell-ul apelant.)
Deci, de unde stau, se pare că este nu este posibil să creați un script shell care este portabil între sistemele Android și non-Android (Linux sau Unix), deoarece Android face lucrurile diferit.
Comentarii
- Din experiența mea,
/bin/sh ar trebui să indice ceva mai asemănător cu bsh sau dash decât bash, care este relativ umflat și astfel preferat pentru utilizare interactivă.
- Câteva greșeli aici. Există încă multe (în mare parte comerciale) Unici pe aici (majoritatea Solaris 10 și versiuni anterioare) unde
/bin/sh este raftul Bourne l, nu un shell POSIX, POSIX nu ' nu specifică calea sh. Cele mai multe cochilii (și execp / env / find -exec...) vor interpreta un she-bang- mai puțin script cu sistemul ' s sh, puțini îl interpretează cu ei înșiși și când o fac, o fac în modul de compatibilitate POSIX. Acesta ' este modul standard / POSIX de a rula scriptul, dar presupune că apelantul se află într-un mediu POSIX .
- În ceea ce privește * BSD
bash este opțional. Înseamnă că există șanse mari ca nici /usr/local/bin/bash să nu existe pe sisteme (ca să nu mai vorbim de sistemele proprietare precum Solaris, AIX sau HP-Ux).
- @ StephaneChazelas – re POSIX, sunt de acord, desigur, și că ' este motivul pentru care cuvintele pe care le-am folosit erau " îndeosebi conforme cu POSIX ". Dar această întrebare a fost despre portabilitate, mai degrabă decât despre locul unde se găsește POSIX și nu se poate ' să se bazeze pe un shell care se găsește întotdeauna într-o singură locație. În ceea ce privește interpretul implicit, un script fără shebang rulat în tcsh este interpretat de tcsh pe FreeBSD. Evident, există și ' inconsecvență acolo, așa că am ' am actualizat răspunsul în consecință.
- @Ouki – da, desigur, doar nu ' nu credeam că este relevant pentru întrebare. Dar eu ' am adăugat acea clarificare la răspunsul pentru claritate.
Din experiența mea, #!/bin/sh și #!/bin/bash au ajuns întotdeauna să găsească mediul potrivit pe câteva sisteme la care am lucrat . Încă nu am întâlnit o excepție. De asemenea, consider că este folosit în mod obișnuit în textele legate de scriptarea shell, care presupun că sunt scrise ținând cont de portabilitate din cauza publicului divers.
Nu se poate spune același lucru cu #!/usr/bin/env.Unele sisteme îl au instalat ca #!/bin/env și mi-au rupt scripturile Python în trecut. Deci, voi merge cu al doilea glonț.
Iată câteva elemente de sprijin pentru afirmația mea de mai sus:
La CentOS lansarea 5.7 primesc următoarele:
$ which env /bin/env
Pe Ubuntu 12.04 Precise Pangolin:
$ which env /usr/bin/env
În plus, cel puțin într-un sistem mai vechi, îmi amintesc administratorii instalat coreutils pe /opt dintr-un anumit motiv (poate să nu fie o bună practică). Deoarece env face parte din coreutils, utilizatorii au ajuns să o primească la /opt/coreutils/bin/env. Desigur, nu am folosit toate sistemele de acolo, așa că răspunsul se bazează pe experiența mea limitată.
Comentarii