Quais recursos estão em zsh e ausentes do bash, ou vice-versa?

Question

Como usuário do Linux, sempre usei o bash porque era o padrão em todas as distros que eu usava. As pessoas que usam outros sistemas Unix, como o BSD, parecem usar outros shells com muito mais frequência. No interesse de aprender um pouco mais, decidi experimentar o zsh.

Como um usuário bash:

• Quais recursos eu vou sentir falta?
• E quais devem eu procurar?

Answer 1

Já houve um pouco de atividade sobre o assunto em outros sites do Stack Exchange. Minha experiência de mudar de bash para zsh, tanto quanto posso lembrar (era anos atrás²), é que eu não perdi uma única coisa. Eu ganhei muito; aqui estão os recursos específicos do zsh que eu mais uso:

• _{O recurso zsh que mais sinto falta quando ocasionalmente uso bash é autocd: em zsh, executar um diretório significa mudar para ele, desde que você ative a opção autocd .⁴}

• Outro recurso muito útil é a globalização extravagante. Os caracteres hieroglyphs são um pouco difíceis de lembrar, mas extremamente convenientes (como em, geralmente é mais rápido consultá-los do que gravar o comando find equivalente). Alguns dos exemplos mais simples:
  foo*~*.bak = todas as correspondências de foo* , exceto as correspondentes a *.bak
foo*(.) = apenas arquivos regulares correspondentes a foo*
foo*(/) = apenas diretórios correspondentes a foo*
foo*(-@) = apenas links simbólicos pendentes que correspondem a foo*
foo*(om[1,10]) = os 10 arquivos mais recentes que correspondem a foo*
foo*(Lm+1) = apenas arquivos de tamanho > 1MB
  _{dir/**/foo* = foo* no diretório dir e todos os seus subdiretórios, recursivamente⁴}

• Para renomear fantasia, o zmv builtin pode ser útil. Por exemplo, para copiar todos os file para file.bak : zmv -C '(*)(#q.)' '$1.bak'

• Tanto o bash quanto o zsh têm um sistema de conclusão decente que precisa ser ativado explicitamente ( . /etc/bash_completion ou autoload -U compinit; compinit ). O Zsh é muito mais configurável e geralmente mais sofisticado.

Se você executar zsh sem .zshrc , ele inicia um menu interativo que permite escolher opções de configuração. (Algumas distribuições podem desabilitar isso; nesse caso, execute autoload zsh-newuser-install; zsh-newuser-install .) Eu recomendo ativar as opções de histórico recomendadas, ativando a conclusão (“novo estilo”) e ativando as “opções comuns de shell”, exceto beep . Mais tarde, configure mais opções conforme você as descobre.

² _{Na época, a conclusão programável era o recurso matador do zsh, mas o bash o adquiriu logo após.}
⁴ _{Recursos que o bash adquiriu apenas na versão 4 (portanto, ainda não estão disponíveis em muitos sistemas) estão em um tipo menor.}

    

Answer 2

Além disso, a conclusão da tabulação padrão é melhor que o bash ... por exemplo ...

~/.e.d TAB irá se expandir para ~/.emacs.d/ em zsh, bash apenas apitará.

    

Answer 3

zsh permite editar um comando de várias linhas (consulte editor de linhas zsh ), bash não faz. Se você tentar o mesmo truque ( Ctrl-p ), o bash buscará o último comando.

    

Answer 4

O Bash tem o recurso de poder abrir portas usando

/dev/tcp/host/port

ou

/dev/udp/host/port

No entanto, ele é desabilitado no Debian, pois é visto como um empecilho (se o caminho realmente existir) e fora do escopo do que um shell deve fazer. Mais informações [mailing list debian]

    

Answer 5

Qual - aprimorado em zsh

O comando which no bash revela apenas a localização de um comando.

Em Zsh which revelará a definição de alias , a origem de function e a localização de um comando.

Digamos que tenhamos um alias de shell:

alias gg='git log'

No Bash, se perguntássemos: which gg , o resultado seria nulo

Em Zsh: which gg nos dará ...

gg: aliased to git log

Digamos que tenhamos uma função de shell:

hello() {
    echo "Hello World"
}

No Bash, se perguntássemos: which hello , o resultado seria anulado.

Em Zsh: which hello nos dará ...

hello() {
    echo "Hello World"
}

    

Answer 6

zsh - um shell completo

existem muitos, lendo zshcontrib(1) pode-se detectar duas versões de autoload -able tetris games (a outra com ncurses ) em zsh em competição com emacs , para completar (como descrito).

=

Gostaria de mencionar a palavra-chave = , que pode causar irritação com curl (as URLs geralmente têm ?var=val , mas é unsetopt , eu acho):

• q file =less ( gentoo ) resolve para q file $(which less)

= expande para o caminho completo do comando em questão.

outras guloseimas

outras coisas, fora da mente, são o prompt direito RPS1=%d (para exibir $PWD no estilo), Alt + H ( run-help ie. man ), < kbd> Alt +? ( which-command ), vared e zed ( autoload function), o minbatffer + Alt + X do Emacs para executar widgets sem vinculá-los, global e sufixo aliases, duração estendida de conclusão de comando do controle de histórico, -m e -regex correspondentes, emulação de shell (por exemplo, csh , ksh com emulate ) e autoload run-help com fragmentos de arquivo para os internos .

lamentações

eu acho que a maioria, se não todos, os recursos foram implementados há muito tempo, e lendo os changelogs, não há grandes mudanças e novas adições de recursos, o que é muito triste (nada para explorar e descobrir mais).

bash parece ser mais distribuído em readline (em oposição a zle ) e gnu history no espírito do linux; Por exemplo, funções de linha de leitura e atalhos de teclado podem ser aplicadas globalmente (conforme mantido em ~/.inputrc e /etc/inputrc ) se não forem sobrepostas por bind específico do bash.

conclusão

Eu pessoalmente acho que emacs (especialmente a perspectiva do (atual?) emacs-nox sabor) ser a inspiração para o software excepcional como zsh e tmux fizeram um bom trabalho em ser um exemplo em tal implementação; para as pessoas que apreciam seu valor (para o nível de não precisar / dependendo do servidor X ). O shell Unix é poderoso o suficiente e sua continuidade e consistência são suficientes para um fluxo de trabalho e produtividade adequados (na computação geral).