intestazione dello script di shell per una migliore compatibilità [duplicate]

Per la portabilità, puoi tranquillamente presumere che #!/bin/sh troverà una shell per lo più conforme a POSIX su qualsiasi sistema Unix o Linux standard, ma questo è tutto.

In FreeBSD, OpenBSD e NetBSD ( insieme a DragonFly, PC-BSD e alcuni altri derivati), bash si trova in /usr/local/bin/bash (se è installato), quindi /usr/bin/env fornisce la portabilità tra Linux e BSD.

Android non è un sistema Unix o Linux standard. Sul mio telefono Android non rootato, nessuno di /usr/bin/env, /bin/bash o r anche /bin/sh esiste e la shell di sistema è /system/bin/sh.

Uno script di shell a cui manca il #! (shebang) tenterà di essere eseguito nella shell che lo ha chiamato su alcuni sistemi, oppure potrebbe utilizzare un interprete predefinito diverso (/bin/bash ad esempio) , su altri sistemi. E sebbene questo possa funzionare su Android, non è garantito che funzioni in altri sistemi operativi, dove gli utenti possono scegliere di utilizzare una shell interattiva diversa da bash. (Uso tcsh in FreeBSD, dove è la shell predefinita, e gli script senza shebang sono interpretati dalla shell chiamante.)

Quindi da dove mi siedo, sembra che sia non è possibile creare uno script di shell che sia portabile tra sistemi Android e non Android (Linux o Unix), perché Android fa le cose in modo diverso.

Commenti

• Nella mia esperienza /bin/sh dovrebbe puntare a qualcosa di più simile a bsh o dash rispetto a bash, che è relativamente gonfio e quindi preferito per luso interattivo.
• Alcuni errori qui. Ce ne sono ancora molti (per lo più commerciali) Unices qui intorno (la maggior parte di loro Solaris 10 e precedenti) dove /bin/sh è lo shel Bourne l, non una shell POSIX, POSIX non ' t specifica il percorso di sh. La maggior parte delle shell (e execp / env / find -exec...) interpreterà uno she-bang- meno script con il sistema ' s sh, pochi lo interpretano da soli e quando lo fanno, lo fanno in modalità di compatibilità POSIX. Questo ' è il modo standard / POSIX di eseguire lo script, ma presuppone che il chiamante si trovi in un ambiente POSIX .
• Informazioni su * BSD bash è facoltativo. Significa che ci sono buone probabilità che anche /usr/local/bin/bash non esista sui sistemi (per non parlare dei sistemi proprietari come Solaris, AIX o HP-Ux).
• @ StephaneChazelas – re POSIX, sono daccordo ovviamente e che ' è il motivo per cui le parole che ho usato erano " per lo più conformi a POSIX ". Ma questa domanda riguardava la portabilità, piuttosto che dove trovare POSIX, e non si può ' fare affidamento sul fatto che una shell venga sempre trovata in una posizione. Per quanto riguarda linterprete predefinito, uno script senza shebang eseguito in tcsh viene interpretato da tcsh su FreeBSD. Ovviamente, anche lì ' è incoerenza, quindi ' ho aggiornato la risposta di conseguenza.
• @Ouki – sì, certo, non ' pensavo che fosse pertinente alla domanda. Ma io ' ho aggiunto questo chiarimento alla risposta per maggiore chiarezza.

Nella mia esperienza, #!/bin/sh e #!/bin/bash hanno sempre trovato lambiente giusto sui pochi sistemi su cui ho lavorato . Devo ancora incontrare uneccezione. Trovo anche che venga utilizzato regolarmente nei testi relativi allo scripting della shell che suppongo siano scritti tenendo presente la portabilità a causa del pubblico diversificato.

Non posso “dire lo stesso con #!/usr/bin/env.Alcuni sistemi lo hanno installato come #!/bin/env e in passato hanno danneggiato i miei script Python. Quindi, vado con il secondo punto.

Ecco un po di supporto per la mia dichiarazione di cui sopra:

Sulla versione 5.7 di CentOS ottengo quanto segue:

$ which env /bin/env 

Su Ubuntu 12.04 Precise Pangolin:

$ which env /usr/bin/env 

Inoltre, almeno in un vecchio sistema, ricordo gli amministratori installato coreutils su /opt per qualche motivo (potrebbe non essere una best practice). Poiché env fa parte di coreutils, gli utenti hanno finito per ottenerlo a /opt/coreutils/bin/env. Devo ammettere che non ho utilizzato tutti i sistemi disponibili, quindi la risposta si basa sulla mia esperienza limitata.

Commenti

• Ad esempio /bin/bash non è sicuramente FreeBSD (sarebbe essere /usr/local/bin/bash poiché bash non fa parte delle shell predefinite).
• ' è piuttosto lopposto: solo alcuni sistemi molto rari mancano di /usr/bin/env (SCO che è barel y esistente, NextStep che è quasi estinto, oltre ovviamente ai più comuni sistemi non unix come Android o Windows). Daltra parte, /bin/bash esiste praticamente solo su Linux non incorporato. /bin/sh è una scommessa sicura su qualsiasi Unix, ma alcuni sistemi meno recenti hanno una shell Bourne non POSIX.
• @Gilles Grazie per le informazioni. Ho aggiornato la mia risposta fornendo alcune prove di ciò che ho visto su alcuni sistemi in cui mi sono imbattuto.
• which env non è ' t rilevante: ci sono diversi sistemi in cui /usr/bin è un collegamento simbolico a /bin o viceversa, il che rende entrambi /usr/bin/env e /bin/env utilizzabile. Ciò che conta è che /usr/bin/env sia presente, come nel caso di tutte le distribuzioni Linux di cui ' ho mai visto o sentito parlare (e rimuovendolo romperebbe così tante cose che nessuno lo farebbe).