Recursos para programação de shell portável

Question

Quais recursos existem para a programação de shell portátil? A resposta final é testar em todas as plataformas segmentadas, mas isso raramente é prático.

A especificação POSIX / Single UNIX é um começo, mas não informa a você qual é o nível de suporte de cada implementação é, nem que existem extensões comuns. Você pode ler a documentação de cada implementação, mas isso consome muito tempo e não é totalmente preciso.

Parece-me que um formato ideal seria algum tipo de versão anotada pela comunidade da especificação POSIX, em que cada recurso é anotado por seu nível de suporte entre as diferentes implementações. Existe uma coisa dessas? Ou existem outros recursos úteis?

_{Por exemplo, há páginas de portabilidade da shell de Sven Mascheck , mas é apenas sobre elementos sintáticos e alguns ins, e só cobre conchas antigas. Eu estou procurando por um recurso mais abrangente.}

    

Answer 1

O manual do autoconf tem uma seção sobre programação de shell portátil .

Embora isso não seja especificamente direcionado ao POSIX, provavelmente é o coleção mais completa do que fazer e não fazer ao tentar para escrever código shell portátil.

    

Answer 2

Além de dash e posh , há bournesh (ou bsh ), o Heirloom Bourne Shell , que pode ser usado para detectar Bashisms .

O Projeto Heirloom também inclui "The Heirloom Toolchest", uma coleção de mais de 100 utilitários Unix padrão (que podem servir como ponto de partida para comparar opções de linha de comando).

    

Answer 3

Semelhante a esta resposta , tente executar seu script em fino .

Além disso, não se esqueça de definir a variável de ambiente POSIXLY_CORRECT como true, pois isso faz com que muitos programas (não apenas o shell) sigam mais estritamente os padrões POSIX.

    

Answer 4

Escrever seus scripts usando o traço pode ser um começo.

    

Answer 5

Para um pouco, você pode tentar checkbashisms no pacote devscripts do Debian / Ubuntu.

Não é perfeito, mas tem o benefício de ser um ponto de partida existente. Por exemplo, ele não vê as falhas clássicas com sed / find referentes ao GNU vs BSD / outras diferenças.

Por padrão, é orientado para o Debian + dash, o -p flag pode ser útil no seu caso.

    

Answer 6

Hoje, normalmente você pode encontrar um shell POSIX em um sistema, e isso geralmente significa que você pode criar scripts na linguagem POSIX (módulo correndo em erros de conformidade).

O único problema é que /bin/sh às vezes não é um shell POSIX. E você deve codificar a linha #! em scripts que devem se comportar como executáveis agradáveis; você não pode simplesmente pedir ao usuário para pesquisar o problema e invocar seu script como /path/to/posix/shell myscript .

Então, o truque é usar recursos POSIX em seu script, mas faça o script encontrar automaticamente o shell POSIX. Uma maneira de fazer isso é assim:

#!/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.

Existem outras abordagens, como geração de código. Boostrap seus scripts com um pequeno script que leva um corpo de arquivos de script sem um #! linha e adiciona um.

A pior coisa que você pode fazer é começar a escrever scripts inteiros de forma que eles sejam executados em um shell Bourne a partir de 1981. Isso só é necessário se você tiver que escrever para um sistema que realmente não tenha qualquer outro shell.