# [troll?] Shell: bash vs Tcsh vs...

## angela

Salut,

je vois encore des gens qui choisissent d'utiliser tcsh. Je ne vois pas vraiment pourquoi utiliser bash, ou tcsh ou encore un autre... google n'aide pas vraiment la dessus... une petite explication ?

merci

----------

## geekounet

On en avait déjà parlé dans ce topic  :Wink: 

Perso j'utilise zsh, parce qu'avec toute les fonctionnalités que ça propose, ça rend vraiment efficace, avec la vraie complétion intelligente (que bash copie très imparfaitement), le globbing avancé, etc. Et mon second préféré c'est le ksh d'OpenBSD. Mais bref je veux pas troller ici.  :Razz: 

----------

## truc

pour un modo, j'trouve que tu trolles pas mal, mais bon... 

Si tu travailles souvent en console (terminal graphique ou pas..), tu pourras profiter des fonctionnalités avancées de ces shells. Tous ne proposant pas les mêmes choses, parmi les trucs les plus cités, on dira que:

zsh à une completion plus avancée que bash, j'ignore comment se fait la complétion zsh (si elle est simple à mettre en place, Batp tu nous dis?) mais, ce qui fait en grande partie la richesse de sa completion, est qu'elle a été faite pour beaucoup d'outils, et que c'est généralement l'install de zsh qui t'installe tout ça à la brutus. 

la completion pour bash, est, bien que souvent dispo, souvent un peu moins à jour complète, et souvent moins intelligente. Mais pour ce que j'en sais, c'est plus une flème des mecs qui l'ont fait qu'un gros manque dans les fonctionnalités de bash (maintenant, faut voir, c'est peut-être effectivement plus facile de faire une completion intelligente pour zsh que pour bash)

Pour ce qui est de mon avis perso, je n'aime pas la completion zsh, et à part pour  les noms de répertoire/fichiers/commandes, j'utilise assez peu la completion, car en général je sais ce que je veux, et ça va plus vite de le taper que de tabuler/valider, mais tout est question de goûts

zsh possède beaucoup de fonctions 'builtin', plus ou moins utiles, une bien utile dont je me servirai volontiers si j'utilisais zsh est le 'find .' que tu fais avec un simple '*/**' si je n'm'abuse. Bapt nous a montré quelques autres fonctionnalités très interessantes de par leur puisance (comprendre: ce que tu tapes en fonction de ce que ça fait) - j'pense par exemple au rename de zsh  :Wink: 

Je n'ai jamais essayé tcsh, et aucun autre en fait, je ne pourrais pas beaucoup t'en parler. Cependant, bash est très souvent sous-estimé. Les personnes s'essayant à zsh par exemple, n'ont très souvent jamais vraiment exploré bash, et sont du coup très impressionnées par zsh, normal! mais rien de si 'impressionnant'

Personnellement, j'utilise *intensivement* readline, (que l'on retrouve dans  bash mais également dans énormément d'autres applications). Le simple fait de devoir se galérer à essayer de reproduire un comportement seulement similaire me rebute.  Cela fait donc également une gros point pour bash à mon avis.

et enfin parmi les quelques trucs typiques de bash auxquels je pense à l'instant et dont je me sers souvent, il y a le '<<<string' cf here-string dans le manuel, le '<(comande) '  cf process substitution dans le manuel,

----------

## Bapt

Bon je vais essayer de ne pas trop rentrer dans le troll, mais je suis parti pris dans ce sujet.

Bon pour commencer le shell le plus répendu par défaut en entreprise reste encore à mon avis ksh c'est le shell par défaut sous Solaris, HP-UX, AIX et OpenBSD par exemple.

Le seul OS à fournir bash comme shell par défaut était jusqu'il y a peu Linux mais OpenSolaris est passé à Bash depuis le projet indiana (OpenSolaris 200805) mais ce choix n'est pas encore figé à ce jour.

Enfin (t)csh est le shell par défaut de freebsd et netbsd

Pour finir l'outdiser est zsh qui n'est présent à ma connaissance comme shell par défaut sur aucun OS (sauf quelques distrib linux : system-rescue-cd par exemple)

En terme de fonctionnalité, ksh parait par défaut un peu rustre de premier abord et dispose souvent de peu de fonctionnalité du point de vue utilisateur, mais attention cela peut varier d'une implémentation à une autre, en effet il existe ksd93 et pdksh qui ne sont pas égaux, mais sont grand atout c'est la programmation il dispose en effet de globbing avancé intéressant et de tout un tas de widget venant du C shell et plus encore. Quand on se plonge dans les arcannes de ksh on se rend compte que l'interraction utilisateur n'est pas si pauvre que ça, au contraire elle est même très évolué mais déroutante pour les gens venant du monde de bash. En particulier je conseillerais à tout le monde d'utliser le mode vi au lieu du mode emacs sous ksh car c'est le shell que je trouve le mieux adapté au mode vi.

Pour ce qui est du (t)csh c'est la même chose, que pour ksh, rebutant au premier abord, il est avant tout intéressant d'un point de vue programmation de scripts. ce qui déroute le plus c'est le fameux rehash qui fait que le PATH et autres ne sont pas reparser dynamiquement pour y ajouter les nouveaux programmes, et que sans un rehash il est impossible de faire la completion sur un nouveau binaire de /bin par exemple ni même de l'exécuter. Je ne connais pas plus (t)csh que ça donc je ne peux pas plus en parler.

Bash aussi je le connais peu, mais il s'est d'abord focaliser sur l'interraction "simple" avec l'utilisateur, ce qui a mon avis à fait son succès, puis sont venus le globbing avancé (sans être extraordinaire non plus) la completion dites avancées (encore une fois un peu décevante), avec les dernières version. Je n'ai pas utilisé bash depuis le début des version 2 (2.03 la dernière que j'ai vraiment testé je crois) donc je ne peux pas trop parler de l'état actuel de ce shell.

Enfin pour ce qui est de mon shell de prédilection, zsh se positionne déjà comme le shell le plus complet, il hérite de (t)csh beaucoup de chose en particulier le fameux rehash qui peut encore en dérouter beaucoup mais le comportement du rehash est plus souple que celui de (t)csh. il dispose de :

- La completion depuis la nuit des temps et de façon poussée (bash-completion est encore et toujours un rajout la ou c'est parti intégrante de zsh depuis longtemps)

- Le globbing avancé reprennant des compatibilité ksh, csh, bash et plus beaucoup de rajout perso.

- des widget haut niveau facilitant le dev de script : (tcp, ftp, ncurses, pcre, etc.)

- ZLE, que l'on peut comparer au readline dont parlait truc, mais en beaucoup plus avancé et souple (il est possible de faire tout ce que l'on veut avec)

- d'implémentation portable de beaucoup de fonctions bas niveau : stat, strftime, etc.

- de plein d'autre bonnes chose qu'il serait trop long à décrire ici  :Smile: 

En ce qui concerne la completion avancée oui elle est très simple à écrire et à "pusher" upstream les devs principaux sont disponibles et très ouvert à intégrer plein de nouveauté rapidement. Elle est centralisée upstream ce qui permet une mise à jours très fréquente des fonctions et un effort centralisé des devs. Elle offre la possibilité d'ajouter une description/documentation lors de la completion des arguments d'une commande, Elle peut apparaitre sous un menus dans lequel on se déplace avec les flèches et la touche entrée pour sélectionner. Elle peut corriger automatiquement les erreurs de frappes etc.

La completion avancée est souvent beaucoup plus rapide de celle de bash car elle dispose d'une possibilité d'utiliser un cache (si le dev de la fonction le prévoie) elle permet de ne pas lancer 36000 grep awk sort uniq cat et autre sed, en effet si vous allez regarder les fonctions de completion bash, elle regorge d'appel à ces programmes qui nuit à la performance et surtout à la portabilité. 

La completion ZSH est tellement poussée et souple qu'elle permet même de reprendre la completion bash (avec bashcompinit).

Si tu recherche un peu mes anciens postes tu en trouveras beaucoup traitant des petites facilité du quotidien.

Pour l'utilisateur final voici quelque exemple intéressant : 

- print -l **/*toto* (==find . -name "*toto*")

- ls -l **/*toto* (== find . -name "*toto*" -ls)

- ls *.avi~*-rc.avi (liste tous les fichiers .avi sauf les fichier *-rc.avi)

- ls **/*.avi~*-rc.avi (idem de manière récursive)

- zmv '(*).AVI' '$1.avi' (renome tous les fichier *.AVI en *.avi combinable avec le globbing avancé biensûr)

- rm -vf **/(*(.old|.OLD|~|.tmp|%|.clz|.toc|%|.bak)|.nfs*|core|\#*|\~\$*)(D.) (nettoie de manière récursive ton arbo (écrit ça proprement sous bash)

Histoire de rajouter une couche concernant ZSH, il permet d'émuler les autres shells : 

emulate -L ksh : emule un ksh

emulate -L csh : emule un csh

emulate -L sh : emule le Almquist SHell (bourne shell de base)

emulate -L bash : emule le bash

donc vous l'aurez compris pour moi c'est zsh partout et en second ksh.

voila par exemple : 

```
toto="5036.235,241.6035"

bla=(${=${${toto//,/ }//./ }})

${(l:4::0:)bla[1]}.${(r:4::0:)bla[2]},${(l:4::0:)bla[3]}.${(r:4::0:)bla[4]}
```

ça transforme "5036.235,241.6035" en "5036.0235,0241.6035" la même chose en bash ferait très mal à la tête je pense.

EDIT: j'avais oublié une fonctionnalité importante : zsh gère le type mimes : ./toto.html ouvre le fichier dans une firefox par exemple  :Smile: Last edited by Bapt on Wed Sep 24, 2008 7:41 am; edited 2 times in total

----------

## xaviermiller

Merci pour cet avis objectif, Bapt  :Smile: 

----------

## truc

 *Quote:*   

>  La completion depuis la nuit des temps et de façon poussée (bash-completion est encore et toujours un rajout la ou c'est parti intégrante de zsh depuis longtemps) 

 C'est justement ce point là que je critiquait plus haut, la completion zsh est disponible pour tout plein d'outils certes. mais.. dans le principe j'trouve ça crade que ça soit installé en même temps que zsh(pour la plus part des complétions j'entends - ce n'est pas le cas pour paludis par exemple..). Personnellement si j'installe zsh, j'trouve étrange de me retrouver avec 25milliard de fichier de completion, pour des outils dont je n'ai que faire...

Mais bon.. on frole le problème éthique là   :Laughing: 

Pour ce qui est de 'ZLE', à comparer avec readline, je trouve *réellement* dommage/préjudiciable que les réglages par défaut ne soit pas semblable à ceux de readline (bon ok la conf de readline change légèrement d'un OS à un autre, mais rien de trop déroutant). 

Il va falloir que je m'essaie un peu plus à ksh, csh et compagnie alors, merci pour ces infos  :Smile: 

----------

## Bapt

 *truc wrote:*   

> Pour ce qui est de 'ZLE', à comparer avec readline, je trouve *réellement* dommage/préjudiciable que les réglages par défaut ne soit pas semblable à ceux de readline (bon ok la conf de readline change légèrement d'un OS à un autre, mais rien de trop déroutant). 

 

Les réglages par défaut de readline sont (si on parle bien de la même chose) les bindings emacs, une simple bindkey -e sous zsh le met en mode emacs avec le même genre de réglage readline, si tu ne parles pas de ça j'aimerai bien savoir de quoi tu parles.

----------

## angela

merci pour ces réponses. Je suis assez temptée à essayer zsh quand j'aurai un peu de temps.

----------

## truc

Je parle bien de ça, mais le comportement n'est pas le même (par défaut) pour des bindings simples, style ^U qui est kill-backward line (à peu près..) avec readline, mais qui te kill toute ta ligne avec ZLE. 

Ça ressemble peut-être à du chipottage... mais c'est quand même un des bindings de base! Y'en avait d'autres, mais c'était l'année dernière, je ne me souviens plus!

Par contre, un grand fan de zsh au boulot (que tu connais bien d'ailleurs bapt... c'est sbz  :Wink:  ) m'a montré, il y a peu, qu'il était possible d'avoir un comportement similaire. (Soit! mais ça reste tout de même un fonctionnement qu'on pourraitt souhaiter avoir par défaut  :Smile:  )

Voili-voilou, sinon je viens en paix, j'discute juste hein  :Smile: 

----------

## Bapt

ouais je connais bien sbz  :Smile: , mais concernant les bindkeys tu peux tous les modifiers, ensuite concernant la conf par défaut de zsh c'est plus aux distribs de faire le taf comme elles le font pour readline que aux devs ZSH.

Sinon je suis bien d'accord que les confs par défaut de zsh sont nulles et que ça peut faire peur à plus d'un utilisateur.

Il faut aussi savoir que si je ne me trompe pas les devs zsh sont tous ou presque utilisateurs du mode vi et non de mode emacs ceci explique aussi peut être pourquoi le mode emacs n'est pas peut être pas compatible avec le readline. Enfin n'utilisant pas emacs peut être que zle respecte le vrai fonctionnement de emacs et pas readline auquel cas il faudrait corriger readline ou l'inverse.

si tu envoies un mails avec la demande concernant les bindkey, je pense que ce sera corriger dans la semaine.

----------

