Usando shells diferentes de bash
Como alguém que está começando a se aprofundar em bioinformática, estou percebendo que, assim como a biologia, existem padrões do setor aqui, semelhantes a Illumina em genômica e gravata borboleta para alinhamento, muitas pessoas usam bash como shell.
Usar um shell além do bash vai causar problemas para mim?
Eu ajustaria os exemplos que você forneceu. Illumina é um padrão para leituras curtas, mas existem muitos laboratórios de genômica trabalhando principalmente com PacBio ou Nanopore. Bowtie dificilmente é um padrão. Mesmo as versões 1 e 2 são muito diferentes.
@burger o que você sugere então?
Sem sugestão. Embora eu concorde com todas as respostas até agora, a bioinformática não é boa com padrões. Mesmo algo como um arquivo SAM / BAM, que é tecnicamente um padrão definido adequadamente que quase todo mundo usa em genômica, tem muitos campos que são tratados de maneira diferente, causando problemas para muitas ferramentas.
Uma afirmação "isso não é para ser opinativo" não ajuda muito com uma questão tão ampla como esta. Você tem um aplicativo específico para o qual gostaria de usar um shell, ou uma indicação de qual "setor" está interessado?
@burger: Você tem campos específicos de SAM / BAM problemáticos em mente? Você pode levantar questões em https://github.com/samtools/hts-specs/issues ou pelo menos isso sugere outra pergunta a fazer aqui ...
@JohnMarshall Não acho que haja um "bug" no padrão SAM / BAM. Só que é aberto e diferentes ferramentas requerem campos diferentes. Tive de modificar meus arquivos BAM muitas vezes no passado porque alguma ferramenta esperava um formato um pouco diferente. Tecnicamente, ainda é um BAM válido antes e depois, mas um é compatível e o outro não. Se você tem um BAM, não tem ideia se ele funcionará com uma ferramenta que requer um arquivo BAM.
@burger: Se você deseja que esta situação melhore, você terá que dizer quais campos específicos você teve que modificar e quais eram as expectativas das várias ferramentas. Se você fizer isso, as especificações podem ser esclarecidas, as ferramentas podem ser modificadas e os canais de bioinformática de todos podem funcionar um pouco mais suavemente. Caso contrário, é apenas FUD.
VCF por outro lado ... :-)
Ferramentas de bioinformática escritas em shell e outros scripts de shell geralmente especificam o shell que desejam usar (via #! / bin / sh ou, por exemplo, #! / bin / bash se for importante), então não será afetado pela escolha do shell do usuário.
Se você está escrevendo scripts de shell significativos, há razões para fazê-lo em um shell do estilo Bourne. Consulte Programação Csh Considerada Nociva e outros ensaios / polêmicas.
Um shell no estilo Bourne é praticamente o padrão da indústria, e se você escolher um shell substancialmente diferente, terá que traduzir parte da documentação de suas ferramentas de bioinformática. Não é incomum ter coisas como
Defina algumas variáveis ​​apontando para os dados de referência e adicione o script ao seu PATH para executá-lo:
Estes serão normalmente mostrados na sintaxe Bourne-shell. Ao usar um shell diferente, você tem que traduzir os comandos export para sua sintaxe local, e especialmente o PATH munging é um pouco dependente do shell.
Se você tem experiência em Unix, isso será apenas uma pequena coisinha. Se você for um iniciante, IMHO, isso adicionará uma quantidade não desprezível de atrito em cima de todas as outras coisas que você está aprendendo.
** Não ** use `#! / Bin / bash` no shebang. Ter o Bash instalado em um local fora do padrão é comum o suficiente para que haja falhas com frequência. Use `#! / Usr / bin / env bash` em vez disso, não deve ter nenhuma desvantagem.
SH adere a um padrão oficial da indústria, mas não é adequado para computação científica. Bash é considerado um padrão informal (por exemplo, pelo Google). Bash 3 é preferível na maioria das situações no mundo da bioinformática.
Como já descrito em outras respostas, SH ( / bin / sh , shell Bourne simples, shell UNIX original) deve aderir totalmente ao POSIX, que é um padrão real da indústria. No entanto, SH é muito limitado para computação científica, pois muitos recursos-chave foram incorporados posteriormente nos sucessores de SH, especialmente no Bash ( / bin / bash , Bourne Again Shell): set -o pipefail , [[...]] ou substituições de processos < () para citar pelo menos alguns.
Na prática, é muito É mais difícil escrever scripts "seguros" em SH puro e apenas os especialistas em shell são geralmente capazes de evitar comportamentos inesperados. Por exemplo, pode ser difícil garantir que nenhum comando em um pipeline falhe no meio da computação. Para o Bash, várias recomendações de programação defensiva fáceis de seguir foram desenvolvidas e devem evitar todos esses problemas. Por esse motivo, muitos cientistas da computação, engenheiros de software e empresas usam o Bash como uma espécie de padrão. Por exemplo, a política interna do Google permite apenas Bash para escrever scripts de shell.
Embora não possamos esperar que o Bash esteja presente em todas as máquinas Unix (por exemplo, em dispositivos móveis como @terdon apontou), a grande maioria das máquinas * nix usadas para computação científica deve tê-lo. Também devemos estar cientes do fato de que o Bash pode ser mais lento que o SH e que recentemente sofreu de problemas de segurança graves. Além disso, existem várias versões do Bash e os scripts que funcionam em máquinas Linux modernas com Bash 4 podem não funcionar no OS X, que ainda é baseado no Bash 3.
Para resumir, Bash 3 é provavelmente a escolha mais razoável para computação científica.
Abordei os comentários de @terdon e @John Marshall. Em particular, acrescentei uma explicação de por que Bash é mais adequado para computação científica do que SH (na minha opinião).
Bash não está presente em todas as máquinas Unix, `sh` está e não é a mesma coisa. Sim, o Linux tende a ter `/ bin / sh` apontando para bash, mas o Linux não é Unix e, de qualquer forma, mesmo no Linux` / bin / sh` nem sempre é `bash` (sistemas baseados em Debian usam traço, por exemplo ) Você pode esperar que o Bourne shell (sh) esteja presente em um sistema compatível com POSIX, mas não necessariamente o Bourne again shell (bash).
@terdon Você poderia fornecer alguma referência, por favor? De acordo com https://wiki.debian.org/Bash, bash é o shell padrão no Debian. Você conhece alguma distro * nix (moderna) onde o bash não seria instalado?
@terdon Vou responder minha pergunta - por exemplo, FreeBSD. https://www.freebsd.org/doc/en/articles/linux-users/shells.html diz que "Bash não está incluído na instalação padrão". Você tem um exemplo de distribuição Linux sem bash?
Alguns (todos?) Sistemas Linux embarcados não terão bash e, em vez disso, terão o busybox sh. O principal problema é que as pessoas tendem a pensar que `sh` e` bash` são a mesma coisa, mas não são. Eles são semelhantes e bash é uma extensão de sh, mas não são iguais.
@Karel: Perguntar sobre o "shell padrão" é ambíguo. De acordo com https://wiki.debian.org/Shell, atualmente no Debian o `/ bin / sh` padrão é o traço, enquanto o shell de login padrão (conforme listado em` / etc / passwd`) permanece `/ bin / bash `. Isso significa que os scripts de shell portáteis que se identificam com `#! / Bin / sh` precisam se restringir aos recursos do shell POSIX, enquanto os scripts que desejam usar extensões bash precisam usar` #! / Bin / bash`. Isso foi arrumado da maneira mais difícil alguns anos atrás, quando várias distribuições mudaram para `/ bin / sh`…
@terdon @John Marshall Obrigado por seus comentários. Comparado ao bash, considero o sh "puro" muito limitado e inapropriado para a computação científica, em particular por causa de alguns recursos ausentes, mas muito importantes, como `set -o pipefail` ou` [[...]] `. Minha experiência é que os scripts sh podem ser muito suscetíveis a comportamento inesperado (a menos que o desenvolvedor seja um especialista em shell, o que geralmente não é o caso em bioinformática). Existem várias estratégias de programação defensiva boas e simples para computação científica para o bash.
É por isso que eu gostaria de saber se `/ bin / bash` pode não retornar nada, ou retornar um shell não-bash (eu vi esse problema apenas uma vez com alguma distribuição de bioinformática obscura).
Eu não faria "computação científica" em um shell, não importa qual seja. O shell deve ser usado para, no máximo, manuseio do encanamento para utilitários e aplicativos básicos. A computação deve ser controlada por utilitários e aplicativos projetados para essas tarefas.
@Kusalananda Como você faz computação científica sem shell? Eu acredito que você o usa pelo menos para executar seus programas. Em caso afirmativo, você concorda que a maneira como ele trata os erros é importante?
@Karel Eu não faria computação de qualquer tipo _sem_ um shell, mas não _in_ (com) um shell.
Estou um pouco intrigado por que essa resposta recomenda o antigo Bash 3 em vez do Bash 4, que já tem quase 10 anos (anunciado em 2009). O Bash 3 carece de recursos cruciais, como matrizes associativas, por isso é uma restrição severa. É verdade que o macOS ainda vem com o Bash 3, mas e daí? O macOS geralmente fica para trás em suas ferramentas Unix (e até mesmo em Ruby e Python). Além disso, nitpick: é "Bash", não "BASH".
@KonradRudolph Obrigado pelo comentário. Corrigi o problema de capitalização. Com relação ao Bash 4, concordo plenamente que ele possui muitos recursos úteis. No entanto, se não puder ser usado em uma proporção substancial de máquinas, é um problema fatal. Enquanto o Python 3 pode ser facilmente instalado (por exemplo, usando Conda), atualizar o Bash é complicado e facilmente resulta em sérios problemas. Quanto aos arrays associativos, o padrão do Google diz o seguinte: "Se você achar que precisa usar arrays para algo mais do que a atribuição de $ {PIPESTATUS}, você deve usar Python."
@Karel Tenho algumas palavras escolhidas para as diretrizes de codificação do Google, nenhuma das quais é aceitável em empresas educadas. De qualquer forma, atualizar o Bash é realmente trivial. Substituí-lo pelo * shell de login * pode não ser, mas na prática isso é desnecessário: no macOS, você especifica o shell no aplicativo de terminal e outros sistemas são fornecidos com o Bash 4.
concordo totalmente com @Kusalananda, tentar escrever seus pipelines inteiramente * em * shell é um erro. Há uma abundância de [estruturas de fluxo de trabalho] (https://github.com/common-workflow-language/common-workflow-language/wiki/Existing-Workflow-systems); Eu sou parcial para Nextflow, e muitos dos meus colegas usam Snakemake. Pipelines totalmente baseados em shell tornam-se rapidamente incontroláveis, excessivamente complexos, confusos para entender e extremamente difíceis de depurar. Se você * deve * usar o Bash, você deve buscar implementações compatíveis com POSIX.
além disso, muitos códigos Bash horríveis para scripts mais simples podem ser realizados melhor com Makefiles. Para iniciantes, você deve tentar aprender como usá-los depois de se familiarizar com o script de shell básico.
As especificações do Open Group Base Issue 7IEEE Std 1003.1 ™ -2008, 2016 Edition, ou "The POSIX Standard" para breve, é o padrão que define as interfaces e utilitários fornecidos por um sistema Unix. Entre eles está a linguagem e ferramentas do shell de linha de comando (consulte "Utilitários Shell &" no índice principal da página com link acima).
Até onde eu sei, não há shell que implemente exatamente o que é especificado pelo padrão, mas ambos bash e ksh93 fazem um bom trabalho em aderir ao padrão junto com suas próprias extensões, às vezes conflitantes. O shell ksh93 em particular teve um grande impacto no desenvolvimento anterior da especificação do shell POSIX, mas as especificações POSIX futuras podem emprestar mais do bash devido ao seu amplo uso no Linux.
O shell bash é praticamente onipresente em sistemas Linux e pode ser instalado em todos os outros Unices também. ksh93 também está disponível para a maioria dos Unices, mas geralmente não é instalado por padrão no Linux. ksh93 está disponível por padrão em pelo menos macOS (como ksh ) e Solaris.
Se você estiver preocupado com a portabilidade ao escrever um script de shell (que se IMHO é uma boa coisa para se preocupar), você deve certificar-se de usar apenas os utilitários POSIX e seus sinalizadores de linha de comando POSIX, bem como usar apenas a sintaxe de shell POSIX. Você deve então assegurar que seu script seja executado por / bin / sh que é suposto ser um shell que entende a especificação POSIX. / bin / sh é frequentemente implementado por bash rodando no "modo POSIX", mas também pode ser traço , ash ou pdksh (ou qualquer outra coisa) dependendo de qual Unix você está usando.
Para um usuário Linux, a parte mais difícil de escrever um script portátil geralmente não é o shell em si, mas a infinidade de sinalizadores de linha de comando não padrão fornecidos pela implementação GNU de muitos utilitários de shell. Os GNU coreutils (utilitários básicos do shell) podem, como o bash , ser instalados em todos os Unices.
Observe também que o bash , quando executado em POSIX modo (quando chamado como / bin / sh ou com seu sinalizador de linha de comando --posix ), não é estrito sobre sua conformidade com POSIX e pode aceitar algumas extensões de sintaxe para o padrão POSIX.
Eu não diria o bash como um "padrão", mas é provável que seja o shell unix mais usado e disponível por padrão na maioria das distros unix / linux modernas. Existem alguns outros shells mais convenientes, como zsh, que são amplamente compatíveis com / bin / sh , mas não estão tão amplamente disponíveis. Também existe o C-shell e, em particular, sua implementação de código aberto tcsh. O C-shell é bem diferente do bash. Há mais de dez anos, vi que era usado de vez em quando, mas hoje em dia raramente vejo seu uso, exceto por programadores de gerações anteriores.
O comando genérico sh é literalmente um padrão da indústria, um padrão POSIX, para ser preciso (IEEE 1003.2 e 1003.2a, disponível para compra por centenas de dólares em vários sites). Em teoria, qualquer script que comece com #! / Bin / sh deve estar em conformidade com este padrão. Na prática, a maioria dos sistemas Linux tem um shell próximo a esse padrão, mas com algumas peculiaridades e extensões.
Problemas surgem quando essas peculiaridades e extensões se tornam práticas padrão em scripts de shell. O sistema operacional Debian mudou para dash como seu shell sh para encorajar as pessoas a parar de usar "bashisms" em scripts de shell que não especificavam um shell particular, ou seja, aqueles que começaram com #! / bin / sh . O shell traço tenta ser o mais compatível com os padrões possível:
traço é o interpretador de comando padrão para o sistema. A versão atual do traço está em processo de alteração para estar em conformidade com as especificações POSIX 1003.2 e 1003.2a para o shell. Esta versão possui muitos recursos que a fazem parecer semelhante em alguns aspectos ao shell Korn, mas não é um clone do shell Korn (consulte ksh (1)). Apenas recursos designados por POSIX, mais algumas extensões de Berkeley, estão sendo incorporados a este shell. Esta página do manual não pretende ser um tutorial ou uma especificação completa do shell.
Não estou familiarizado com as diferenças, e geralmente tento manter o sh páginas de manual para me instruir sobre os scripts de shell corretos em conformidade com os padrões.
Observe que sh não é bash. Mesmo em sistemas cujo `/ bin / sh` aponta para` bash`, ser invocado como `sh` muda o comportamento do bash e faz com que ele rode no modo compatível com POSIX. O shell `sh`" real "(shell bourne) é outra coisa e não o mesmo que` bash` (shell bourne again).
No Debian, o shell interativo padrão, ou seja, aquele que você usará na linha de comando é bash https://wiki.debian.org/Shell yes `/ bin / sh` será simbolizado em` / bin / dash` mas aquele que as pessoas usarão ao vivo será o bash.