shell szkript fejléc a legjobb kompatibilitás érdekében [duplicate]

A hordozhatóság érdekében nyugodtan feltételezheti, hogy A #!/bin/sh többnyire POSIX-kompatibilis shell-t fog találni bármely szokásos Unix vagy Linux rendszeren, de ez tényleg erről szól.

FreeBSD, OpenBSD és NetBSD ( a DragonFly, a PC-BSD és néhány más származékkal együtt), a bash a /usr/local/bin/bash helyen található (ha telepítve van), így a /usr/bin/env megközelítés biztosítja a hordozhatóságot a Linux és a BSD között.

Az Android nem egy szabványos Unix vagy Linux rendszer. A nem gyökérzetű androidos telefonomon egyik /usr/bin/env, /bin/bash o r even /bin/sh létezik, és a rendszerhéj /system/bin/sh.

Olyan shell parancsfájl, amelyből hiányzik a #! (shebang) megpróbálja futtatni a héjat, amely néhány rendszeren meghívta, vagy használhat más alapértelmezett tolmácsot (például /bin/bash) , más rendszereken. És bár ez működhet az Android rendszerben, nem garantáltan működik más operációs rendszerekben, ahol a felhasználók választhatnak olyan interaktív héjat, amely nem bash. (A tcsh-t használom a FreeBSD-ben, ahol ez az alapértelmezett shell, és a shebang nélküli szkriptet a hívó shell értelmezi.)

Tehát onnan, ahonnan én ülök, úgy tűnik, hogy ez nem lehetséges az Android és a nem Android (Linux vagy Unix) rendszerek között hordozható shell szkript létrehozása, mert az Android másképp csinálja a dolgokat.

Megjegyzések

• Tapasztalatom szerint /bin/sh állítólag valami többre mutat, például bsh vagy dash mint bash, amely viszonylag dagadt és ezért inkább interaktív használatra alkalmas.
• Néhány hiba itt. Még mindig sok (főleg kereskedelmi) Körülötte lévő egységek (többségük Solaris 10 és korábbi), ahol /bin/sh a Bourne-menedék l, nem POSIX héj, a POSIX nem adja meg a ' t a sh útvonalát. A legtöbb héj (és execp / env / find -exec...) értelmezni fog egy kevesebb szkript a rendszerrel ' s sh, kevesen értelmezik önmagukkal, és amikor mégis, akkor POSIX kompatibilitási módban csinálják. Ez ' a szkript futtatásának szokásos / POSIX módja, de feltételezi, hogy a hívó POSIX környezetben van.
• b> * BSD bash nem kötelező. Ez azt jelenti, hogy jó esély van arra, hogy még /usr/local/bin/bash sem létezik a rendszereken (nem beszélve a saját rendszerekről, mint a Solaris, AIX vagy a HP-Ux).
• @ StephaneChazelas – re POSIX, természetesen egyetértek, és hogy ' miért voltak az általam használt szavak többnyire POSIX-kompatibilisek ". De ez a kérdés a hordozhatóságról szólt, nem pedig arról, hogy hol találja meg a POSIX-ot, és nem lehet ' támaszkodni arra, hogy egy héj mindig egy helyen található. Az alapértelmezett tolmács tekintetében a tcsh-ben futtatott shebang nélküli szkriptet a tcsh értelmezi a FreeBSD-n. Nyilvánvaló, hogy ' ott is következetlenség áll fenn, ezért ' ennek megfelelően frissítettem a választ.
• @Ouki – igen, persze, nem gondoltam ', hogy ez releváns a kérdés szempontjából. De ' az egyértelműség kedvéért hozzáadtam ezt a pontosítást a válaszhoz.

Tapasztalataim szerint #!/bin/sh és #!/bin/bash mindig megtalálták a megfelelő környezetet azon a néhány rendszeren, amin dolgoztam . Még nem találkoztam kivétellel. Azt is tapasztalom, hogy rutinszerűen használják a shell-szkriptekkel kapcsolatos szövegekben, amelyek feltételezésem szerint a sokféle közönség miatt szem előtt tartva a hordozhatóságot írják.

Nem mondhatja el ugyanezt a #!/usr/bin/env.Néhány rendszer #!/bin/env néven telepítette, és korábban megszakították a python szkriptjeimet. Tehát a második gombbal megyek.

Íme néhány támogatás a fenti állításomra:

A CentOS 5.7 kiadásánál a következőt kapom:

$ which env /bin/env 

Az Ubuntu 12.04-es Pontos Pangolinnal:

$ which env /usr/bin/env 

Ezenkívül legalább egy régebbi rendszerben emlékszem az adminokra a coreutils webhelyet valamilyen okból telepítette (lehet, hogy nem ez a legjobb gyakorlat). Mivel a env a coreutils része, a felhasználók végül a (z) /opt/coreutils/bin/env telefonszámon kapták meg. Kétségtelen, hogy nem használtam fel minden rendszert odakint, így a válasz korlátozott tapasztalataimon alapul.

Megjegyzések

• Például a /bin/bash biztosan nem a FreeBSD (lenne legyen /usr/local/bin/bash, mivel a bash nem része az alapértelmezett héjaknak).
• Ez ' inkább az ellenkezője: csak néhány nagyon ritka rendszerből hiányzik a /usr/bin/env (SCO y fennmaradt, a NextStep, amely csak kihalt – plusz természetesen a leggyakoribb nem unix rendszerek, mint például az Android vagy a Windows). Másrészt a /bin/bash jóformán csak nem beágyazott Linuxon létezik. A /bin/sh biztonságos fogadás bármilyen unix-re, de néhány régebbi rendszerben ott van egy nem POSIX Bourne-héj.
• @Gilles Köszönöm az információt. Frissítettem válaszomat, és bizonyítékot szolgáltattam arra, amit néhány rendszeren láttam.
• which env isn ' t releváns: elég sok olyan rendszer van, ahol az /usr/bin szimbólum link a /bin -hez, vagy fordítva, ami mindkét /usr/bin/env és /bin/env használható. Ami fontos, hogy /usr/bin/env jelen van, ez minden olyan Linux disztribúció esetében érvényes, amiről valaha ' láttam vagy hallottam (és eltávolítottam) annyi mindent megtörne, hogy senki sem tenné).