Risorse per la programmazione di shell portatili

Quali risorse esistono per la programmazione della shell portatile? La risposta definitiva è testare su tutte le piattaforme target, ma raramente è pratico.

La specifica POSIX / Single UNIX è un inizio, ma non ti dice né quale sia il livello di supporto di ogni implementazione, né quali estensioni comuni esistono. Puoi leggere la documentazione di ogni implementazione, ma è molto dispendiosa in termini di tempo e non completamente accurata.

Mi sembra che un formato ideale sarebbe una sorta di versione annotata dalla comunità delle specifiche POSIX, in cui ogni funzione è annotata dal suo livello di supporto tra le diverse implementazioni. C'è una cosa del genere? O ci sono altre risorse utili?

_{Ad esempio, ci sono le pagine sulla portabilità della shell di Sven Mascheck , ma si tratta solo di elementi sintattici e di alcuni built-in, e copre solo vecchie shell. Sto cercando una risorsa più completa.}

Il manuale di autoconf ha una sezione sulla programmazione della shell portatile .

Sebbene non sia specificamente destinato a POSIX, è probabilmente la raccolta più completa di cosa fare e non fare quando si tenta di scrivere codice shell portatile.

Oltre a dashe posh, c'è bournesh(o bsh), Heirloom Bourne Shell , che può essere usato per rilevare i Bashismi .

Il progetto Heirloom include anche "The Heirloom Toolchest", una raccolta di oltre 100 utility Unix standard (che potrebbero servire come punto di partenza per confrontare le opzioni della riga di comando).

Simile a questa risposta , prova a eseguire il tuo script in posh .

Inoltre, non dimenticare di impostare la POSIXLY_CORRECTvariabile di ambiente su true, poiché questo fa sì che molti programmi (non solo la shell) aderiscano più strettamente agli standard POSIX.

Scrivere i tuoi script usando dash potrebbe essere un inizio.

In una certa misura, puoi provare checkbashismsnel devscriptspacchetto Debian / Ubuntu .

Non è perfetto, ma ha il vantaggio di essere un punto di partenza esistente. Ad esempio, non vede le anomalie classiche con sed/ findriguardanti GNU vs BSD / altre differenze.

Per impostazione predefinita, è Debian + dash dash, la -pbandiera può essere utile nel tuo caso.

Oggi, di solito è possibile trovare una shell POSIX su un sistema, e ciò significa generalmente che è possibile eseguire lo script nel linguaggio POSIX (modulo in esecuzione in bug di conformità).

L'unico problema è che a /bin/shvolte non è una shell POSIX. E devi codificare la #!linea in script che devono comportarsi come un buon eseguibile; non puoi semplicemente chiedere all'utente di ricercare il problema e quindi invocare il tuo script come /path/to/posix/shell myscript.

Quindi, il trucco è usare le funzionalità POSIX nel tuo script, ma fare in modo che lo script trovi automaticamente la shell POSIX. Un modo per farlo è così:

#!/bin/sh

# At this point, we may be running under some old shell
# we have to tread carefully.

# note how we use test rather than [ ] syntax and avoid
# depending on test with no argument producing a failure;
# i.e. "test $posix_shell".

if ! test x$posix_shell = x ; then
  # the three possible shell paths are just an example;
  # please extend as necessary.

  for shell in /usr/xpg4/bin/sh /bin/bash /usr/bin/bash ; do
    if test -x $shell ; then
       posix_shell=$shell
    fi
  done
  if test x$posix_shell = x ; then
    echo "no POSIX shell found"
    exit 1
    # or we could avoid bailing here and just fall back on /bin/sh:
    # echo "falling back on /bin/sh: cross your fingers that it works"
    # posix_shell=/bin/sh
  fi
  export posix_shell

  # plain "$@" is broken in ancient shells! 
  # I seem to recall ${@+"$@"}: not sure if that's the right trick.

  exec $posix_shell $0 ${@+"$@"}  # can we count on exec in legacy shells? 
fi

# phew, at this point in the script we have been re-executed and are
# being interpreted by some reasonably modern shell. We can use $(...)
# command substitution, and other features.

Esistono altri approcci, come la generazione di codice. Boostrap i tuoi script con un piccolo script che prende un corpo di file di script senza un #! linea e ne aggiunge uno.

La cosa peggiore che puoi fare è iniziare a scrivere interi script in modo tale che vengano eseguiti su una shell Bourne dal 1981. Questo è necessario solo se devi scrivere per un sistema che in realtà non ha altre shell .