Comentários
- É realmente sobre o quão portátil você deseja ser . Apenas Unixes? Todas as caixas baseadas no kernel Linux? Todos os sistemas, mesmo antigos Win 3.0 e VMS (brincando)?
/bin/shgeralmente é um bom mínimo, mas esteja ciente de queshnão ébash.. .esperado na maioria dos sistemas GNU / Linux . - Embora o Android use o kernel do Linux e o shell padrão seja derivado do bash via ash, a área de usuário não é muito semelhante ao Unix e sem muitas ferramentas padrão.
Resposta
Para portabilidade, você pode assumir com segurança que #!/bin/sh encontrará um shell compatível com POSIX em qualquer sistema Unix ou Linux padrão, mas isso é realmente sobre isso.
No FreeBSD, OpenBSD e NetBSD ( junto com o DragonFly, PC-BSD e alguns outros derivados), o bash está localizado em /usr/local/bin/bash (se estiver instalado), então o /usr/bin/env abordagem fornece portabilidade entre Linux e BSD.
O Android não é um sistema Unix ou Linux padrão. No meu telefone Android sem root, nenhum dos /usr/bin/env, /bin/bash o r até /bin/sh existem, e o shell do sistema é /system/bin/sh.
Um script de shell sem o #! (shebang) tentará executar no shell que o chamou em alguns sistemas ou pode usar um interpretador padrão diferente (/bin/bash por exemplo) , em outros sistemas. E embora isso funcione no Android, não é garantido que funcione em outros sistemas operacionais, onde os usuários podem optar por usar um shell interativo que não seja bash. (Eu uso tcsh no FreeBSD, onde é o shell padrão, e o script shebang-less é interpretado pelo shell de chamada.)
Então, de onde estou, parece que é não é possível criar um script de shell que seja portátil entre sistemas Android e não Android (Linux ou Unix), porque o Android faz as coisas de maneira diferente.
Comentários
- Na minha experiência,
/bin/shdeve apontar para algo mais comobshoudashdo quebash, que é relativamente inchado e, portanto, preferido para uso interativo. - Alguns erros aqui. Ainda há muitos (principalmente comerciais) Unices por aqui (a maioria deles Solaris 10 e anteriores), onde
/bin/shé o shel Bourne l, não é um shell POSIX, o POSIX não ' t especifica o caminho desh. A maioria dos shells (eexecp/env/find -exec...) interpretará um she-bang- menos script com o sistema ' ssh, poucos interpretam com eles mesmos e quando o fazem, o fazem no modo de compatibilidade POSIX. Essa ' é a maneira padrão / POSIX de executar o script, mas assume que o chamador está em um ambiente POSIX . - Em relação a * BSD
bashé opcional. Isso significa que há boas chances de que mesmo/usr/local/bin/bashnão exista nos sistemas (para não mencionar sistemas proprietários como Solaris, AIX ou HP-Ux). - @ StephaneChazelas – re POSIX, concordo, é claro, e que ' é por isso que as palavras que usei eram " em sua maioria compatíveis com POSIX ". Mas essa questão era sobre portabilidade, ao invés de onde encontrar POSIX, e não se pode ' confiar em um shell sempre sendo encontrado em um local. Com relação ao interpretador padrão, um script shebang-less executado em tcsh é interpretado por tcsh no FreeBSD. Obviamente, há ' s inconsistência lá também, então ' atualizei a resposta de acordo.
- @Ouki – sim, claro, eu não ' achei que isso fosse relevante para a pergunta. Mas eu ' acrescentei esse esclarecimento à resposta para maior clareza.
Resposta
Na minha experiência, #!/bin/sh e #!/bin/bash sempre acabaram encontrando o ambiente certo nos poucos sistemas em que trabalhei . Ainda não encontrei uma exceção. Também acho que é usado rotineiramente em textos relacionados a scripts de shell que suponho que tenham sido escritos tendo a portabilidade em mente devido ao público diverso.
Não posso dizer o mesmo com #!/usr/bin/env.Alguns sistemas o têm instalado como #!/bin/env e quebraram meus scripts Python no passado. Então, vou com o segundo item.
Aqui está um pouco de suporte para minha declaração acima:
No CentOS versão 5.7 eu obtenho o seguinte:
$ which env /bin/env No Ubuntu 12.04 Precise Pangolin:
$ which env /usr/bin/env Além disso, pelo menos em um sistema mais antigo, lembro-me dos administradores instalado coreutils em /opt por algum motivo (pode não ser uma prática recomendada). Desde env faz parte de coreutils, os usuários acabaram conseguindo em /opt/coreutils/bin/env. Reconheço que não usei todos os sistemas lá fora, então a resposta baseia-se na minha experiência limitada.
/bin/bashdefinitivamente não é FreeBSD (seria seja/usr/local/bin/bashjá que o bash não faz parte dos shells padrão)./usr/bin/env(SCO que é barel y existente, NextStep que está quase extinto – além, é claro, dos sistemas não-unix mais comuns, como Android ou Windows). Por outro lado,/bin/bashpraticamente só existe no Linux não integrado./bin/shé uma aposta segura em qualquer Unix, mas alguns sistemas mais antigos têm um shell Bourne não POSIX lá.which envisn ' t relevante: existem alguns sistemas em que/usr/biné um link simbólico para/binou vice-versa, o que torna ambos/usr/bin/enve/bin/envutilizável. O que importa é que/usr/bin/envestá presente, o que é o caso em todas as distribuições Linux que eu ' já vi ou ouvi falar (e removendo-o quebraria tantas coisas que ninguém faria).