É recomendado usar zsh em vez de scripts bash? [fechadas]

Posso assumir que pessoas suficientes foram zshinstaladas para executar scripts com um

#!/usr/bin/env zsh

como shebang?

Ou isso tornará meus scripts impossíveis de executar em muitos sistemas?

Esclarecimento: Estou interessado em programas / scripts que um usuário final pode querer executar (como no Ubuntu, Debian, SUSE, Arch etc.)

Para portabilidade, não. Embora zshpossa ser compilado em qualquer Unix ou Unix-like e até Windows pelo menos via Cygwin, e é empacotado para a maioria dos gostos Open Source Unix e vários comerciais, geralmente não é incluído na instalação padrão.

bashpor outro lado, é instalado nos sistemas GNU (como bashé o shell do projeto GNU), como a grande maioria dos sistemas Linux não incorporados e, às vezes, nos sistemas não-GNU, como o Apple OS / X. No lado comercial do Unix, o shell Korn (a variante AT&T, embora seja mais a ksh88mesma) é a norma e ambos bashe zshestá em pacotes opcionais. Sobre os BSDs, o shell interativo preferido é muitas vezes tcshenquanto shestá baseado ou no shell Almquist ou pdkshe bashou zshnecessidade de ser instalado como pacotes opcionais também.

zshé instalado por padrão no Apple OS / X. Até costumava estar /bin/shlá. Por padrão, ele pode ser encontrado em algumas distribuições Linux como SysRescCD, Grml, Gobolinux e provavelmente outras, mas não acho nenhuma das principais.

Por exemplo bash, há a questão da versão instalada e, como conseqüência, dos recursos disponíveis. Por exemplo, não é incomum encontrar sistemas com bash3ou zsh3. Além disso, não há garantia de que o script para o qual você escreve agora zsh5funcione, zsh6embora como basheles tentem manter a compatibilidade com versões anteriores.

Para scripts, minha visão é: use a sintaxe do shell POSIX, pois todos os Unices têm pelo menos um shell chamado sh(não necessariamente em /bin) capaz de interpretar essa sintaxe. Então você não precisa se preocupar muito com a portabilidade. E se essa sintaxe não for suficiente para sua necessidade, provavelmente você precisará de mais do que um shell.

Então, suas opções são:

• Perl que é onipresente (embora, novamente, você precise se limitar ao conjunto de recursos de versões antigas e não possa fazer suposições sobre os módulos Perl instalados por padrão)
• Especifique o interpretador e sua versão (python 2.6 ou superior, zsh 4 ou superior, bash 4.2 ou superior ...), como uma dependência do seu script, criando um pacote para cada sistema de destino que especifique a dependência ou estipulando-o em um arquivo LEIA-ME enviado junto com o script ou incorporado como comentários na parte superior do script ou adicionando algumas linhas na sintaxe Bourne no início do script para verificar a disponibilidade do intérprete solicitado e dar um erro explícito quando não é, esse script precisa do zsh 4.0 ou superior .
• Envie o intérprete juntamente com o seu script (cuidado com as implicações do licenciamento), o que significa que você também precisa de um pacote para cada SO direcionado. Alguns intérpretes facilitam isso, fornecendo uma maneira de compactar o script e seu intérprete em um único executável.
• Escreva em um idioma compilado. Novamente, um pacote por sistema de destino.

Não, você não pode. O que é garantido disponível é /bin/shessencialmente o shell Bourne original. Quase todas (observe o "quase"!) As instalações do Linux terão o bash, mas em sistemas * BSD é raro (a opinião do BSD tem sérias dúvidas sobre o código GPL, como o bash). Não sei qual é o shell padrão no Mac, mas, novamente, existem dúvidas sobre a GPL. O mesmo para Solaris.

O zsh é um shell de nicho, não está na instalação padrão do Fedora (e eu não acredito que seja o padrão para qualquer grande distribuição).

Eu acho que realmente depende de quais recursos extras do zsh você está usando e de onde. Se você planeja distribuir seu script entre os diferentes usuários e sistemas, sugiro usar o bash ou mesmo sh .

Ao mesmo tempo, se o seu script foi projetado para ser executado em toda a organização e você tiver a convenção de ter o zsh em suas máquinas (por exemplo, a mesma AMI básica) e sua tarefa tiver benefícios claros de extensões como seletores de arquivos avançados ou outros itens de http: / /www.rayninfo.co.uk/tips/zshtips.html Eu diria que vá em frente!

Como afirmado, bashgeralmente está disponível na instalação padrão para muitas distribuições. Seu script não alcançará a melhor base de usuários contando com zsh.

Uma pergunta importante a ser respondida antes de projetar seu script é " Por que importa em qual shell um script é executado? "

Os shells diferentes usam sintaxe diferente ou oferecem funções adicionais do shell que podem não ser suportadas por outros shells. Para escrever um script para o "mundo geral do usuário final do linux", determine se o script usa alguma sintaxe ou função de shell que dependa de um ambiente de shell específico.

Por exemplo, o bashshell suporta certas expansões que não são suportadas pelo dashBourne shell ou o que quer que /bin/shaponte para o sistema do usuário.

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Feb 19  2014 /bin/sh -> dash

Tente executar echo {1..10}com /bin/shcomparado a /bin/bashe você obterá resultados muito diferentes.

O mesmo vale para o zshqual, embora bashofereça suporte à maioria das sintaxes, oferece expansão e sintaxe adicionais que não são suportadas pelo bashshell. Veja esta tabela comparando shells para exemplos específicos.

Você pode ampliar sua base de usuários em potencial bash, aderindo a scripts que funcionam quando chamados #!/bin/sh -u. No entanto, isso suscita outra questão importante a ser feita: " O que está sendo sacrificado em troca de uma maior portabilidade? "

Determine se as diferenças relacionadas a questões de segurança, funcionalidade, eficiência ou qualquer outra coisa que você considere ser uma prioridade para o seu script valeriam o sacrifício. Talvez você não queira o uso generalizado de um script com uma vulnerabilidade de segurança conhecida apenas porque funciona em mais ambientes.

Muitos scripts são escritos para bashque o suporte a esses scripts seja usado como critério ao comparar shells de comandos . Muito mais pessoas poderão executar seu script do que se ele confiar zshou em qualquer outra sintaxe exclusiva de um ambiente shell.

Além disso, lembre-se de que você não tem controle sobre como o usuário executa o script (também útil para depurar scripts em diferentes shells ):

Lembre-se de que se você usar um shell para ler um script de shell ("sh scriptname"), em vez de executá-lo diretamente ("./scriptname"), o shell tratará todos os comentários no início do script como comentários. Em particular, o comentário que especifica o intérprete a ser usado ao executar o script (“#! / Bin / sh -u”) será ignorado, assim como todas as opções listadas ao lado desse intérprete.

Portanto, o melhor que você pode fazer sobre isso é tornar seus scripts portáteis, desde que não exista grande sacrifício em como ele funciona.

Você também pode ver convenções de codificação Bash - Stack Overflow .

A única coisa que você quase pode garantir é que existe um /bin/sh. Pode ser um shell vinculado realmente estático ou pode ser um link para outro shell. Esse outro shell geralmente detecta que é chamado de sh e será executado no modo de compatibilidade.

Observe o quase na primeira frase.

Todo sistema como o Unix que eu já trabalhei tinha. Muitos deles também tinham o bash instalado (mas nem todos . Por exemplo, o bash não é instalado por padrão em alguns BSDs. Alguns distribuidores Linux são fornecidos com o DASH , o shell Debian Almquist.

O que você pode garantir são as instruções de instalação. Você pode adicionar uma linha ao arquivo README informando que é necessário o zsh. Se você criar um pacote, poderá marcar o zsh como uma dependência. Você pode verificar isso com as ferramentas autoconf / automake. Você pode verificar se o zsh foi encontrado no script de instalação (inicie com / bin / sh e tente localizar o zsh, se for encontrado continuar. Se não houver um erro. Por exemplo, "Aviso: o ZSH não está instalado. Leia o arquivo de instruções de instalação! ".)

Tenho certeza de que esqueci mais algumas opções. Mas os pontos principais são:

• Você não pode garantir nada até verificá-lo.
• Você está quase garantido que / bin / sh está presente e que você pode verificar isso.