Sondage Dans quel shell tapez-vous vos lignes de commandes ?

Posté par Bruno Michel (site web personnel) le 11 avril 2018 à 17:43. Licence CC By‑SA.

Étiquettes : aucune

avr.

2018

Selon Wiktionary: Interface utilisateur d’un système d’exploitation, principalement destinée à lancer d’autres programmes et gérer leurs interactions. Le terme est généralement utilisé pour parler d’une interface en ligne de commande. La norme ISO/IEC 2382-28:1995 donne les traductions « coquille » et « système essentiel ».

Le solide Bash :
1227
(52.4 %)
Le puissant Zsh :
500
(21.4 %)
Le flexible Fish :
61
(2.6 %)
Le surprenant PowerShell :
53
(2.3 %)
N'importe quel shell compatible Posix :
36
(1.5 %)
Le shell par défaut de ma distribution :
328
(14.0 %)
Le shell intégré à mon IDE ou terminal :
31
(1.3 %)
Un autre shell :
37
(1.6 %)
Pas de lignes de commande, pas de shell :
14
(0.6 %)
Ça c'est sûr, sachez savamment passer au shell choisi, d'un changement tranché sèchement. :
53
(2.3 %)

Total : 2340 votes

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

# bash, le shell le plus lisible

Posté par feth le 11 avril 2018 à 18:13. Évalué à 10.

:; ______=$? __=${#______} ____=$[__+__] ________=$[__+____] _____=$[____+____]
     __________=$[____+_____] _________=$[__+__________] ______________=(
            /????/$$/????) ____________=${______________[$______]} 
   _____________=${____________##*/} _______________=(${____________//\// })
          ________________=${_______________: -$__:$__}$_____________
           ___________________=${________________:$______:$________}
   ___________=${_____________:$______:$__} _________________=${___________^}
     . <($___________________<<<__________________=\({$_________________..\
${___________}}\))&&_______=(${__________________[@]:$______:$____$__________})
  ___=(${_______[@],,})&&${___[$_____]}${___[$____]}${___[$_________]}${___[
$__$_____]} -${___[$_____]} ${_______[ $_________]}${___[${_____}]}${___[$__$__
]}${___[$__$__]}${___[$__$_____]} ${_______[$____$____]}${___[$__$_____]}${___[
$__$_________]}${___[ $__$__]}${___[$________]}\\$______$[$_____#$____$____$__]

(chouravé réponse 33 de ce concours de masquage de "hello world" )

# ksh

Posté par Micromy (site web personnel) le 11 avril 2018 à 21:49. Évalué à 4.

Bon, chez moi c'est bash, souvent parce-que c'est par défaut sur les distributions que j'utilise (Mageia & Debian), mais professionnellement c'est ksh, le standard de mon employeur.
- [^] # Re: ksh
  
  Posté par claudex le 12 avril 2018 à 09:49. Évalué à 3.
  
  Vous utilisez OpenBSD en standard ?
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: ksh
    
    Posté par goernil le 12 avril 2018 à 10:25. Évalué à 5. Dernière modification le 12 avril 2018 à 10:26.
    
    En pro, c'est ksh sur AIX
    - [^] # Re: ksh
      
      Posté par WormRider le 19 avril 2018 à 17:48. Évalué à 0.
      
      Sur tous les unix commerciaux c'est Ksh , -o vi !!
# bash et dash

Posté par Olivier Esver (site web personnel) le 11 avril 2018 à 22:47. Évalué à 3. Dernière modification le 11 avril 2018 à 22:49.

Le shell par défaut sur mes distributions (debian et ubuntu)

S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
# bash parce bash

Posté par Maclag le 11 avril 2018 à 22:50. Évalué à 7.

Bash a toujours été le shell par défaut de toutes mes distros, et du coup je ne connais que celui-là. Je ne me sers pas assez des choses subtiles pour rentabiliser la différence avec d'autres.
Du coup, je repasse en bash si confronté à un environnement hostile (c'est-à-dire inconnu).

Mais si toutes les distros avaient mis autre chose, je serais certainement sur autre chose…
- [^] # Re: bash parce bash
  
  Posté par Lutin le 12 avril 2018 à 00:03. Évalué à 8.
  
  J'ai commencé à utiliser zsh quand on m'a dit que c'était tout comme bash, mais avec une vraie complétion automatique, et c'est vrai que ça change la vie.
  - [^] # Re: bash parce bash
    
    Posté par freem le 12 avril 2018 à 11:22. Évalué à 7.
    
    Le problème avec zsh, c'est que la touche tab est usée plus vite, vu qu'elle sert réellement à quelque chose… enfin, le fait que l'on n'en aie besoin qu'une fois pour traverser une arborescence complète compense un peu le problème (ça me fait penser, il faudrait que je voie pourquoi ma complétion pour les pages de manuel est cassée… alors que je m'en servait encore il y a quelques semaines pour avoir la doc de la lib standard de C++. Peut-être un problème lié à stdman?).
    
    Plus sérieusement, je trouve que d'une part zsh à une bien meilleure auto-complétion, mais je le trouve aussi plus réactif (je n'ai pas fait de mesures, c'est juste un ressenti) et cerise sur le gâteau, il ne fout pas tous ses fichiers en vrac dans le $HOME! Enfin, si, mais on peut le configurer pour qu'il soit propre, contrairement à bash.
    - [^] # Re: bash parce bash
      
      Posté par jihele le 12 avril 2018 à 15:57. Évalué à 2.
      
      J'ai déjà eu un aperçu rapide de fonctionnalités que j'aimais bien mais le jour où j'ai voulu essayer chez moi, j'ai pas su le configurer, ou bien j'ai pas trouvé d'exemple de config sympa pour gagner du temps.
      
      J'ai pas du prendre le temps de chercher, mais disons que c'était pas juste aptitude install zsh, il faut ensuite configurer. Et je perds déjà assez de temps avec vi…
      - [^] # Re: bash parce bash
        
        Posté par freem le 12 avril 2018 à 16:15. Évalué à 3.
        
        C'est clair qu'il faut le configurer le bouzin, mais normalement, en 1er lancement, tu as un outil qui te pose les questions pour configurer l'auto-complétion déjà.
        Le reste, il faut fouiller la doc, mais perso je reste à un usage relativement simple, tout ce que je demande, c'est une complétion propre, un prompt qui change de couleur selon la machine sur laquelle je suis et l'utilisateur (rouge et rouge quand je suis root sur une machine distante notamment, histoire de me rappeler de finir ma session ASAP et sans faire de connerie) et de pas mettre le boxon dans mon $HOME.
        Du coup, c'est assez trivial, mais impossible avec bash (sauf pour les couleurs, bien sûr).
        
        Le fait est que, pour config bash correctement, c'est pareil mais en pire, ne serait-ce que parce que la manpage est d'une qualité bien différente.
      - [^] # Re: bash parce bash
        
        Posté par Lutin le 13 avril 2018 à 13:50. Évalué à 3.
        
        Avec oh-my-zsh tu as juste un git clone à faire et un script à lancer.
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 18 avril 2018 à 18:20. Évalué à 3. Dernière modification le 18 avril 2018 à 18:23.
        
        Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: bash parce bash
    
    Posté par Matthieu Moy (site web personnel) le 13 avril 2018 à 09:52. Évalué à 5.
    
    Ceci dit, bash a aussi une complétion intelligente, et elle est activée dans /etc/bash.bashrc (. /etc/bash_completion ou quelque chose qui ressemble) par la plupart des distribs. Celle de zsh est plus avancée, mais bash est déjà pas mal du tout.
    
    Une autre killer-feature qui m'avait fait passer à ZSH était le globbing avec **, mais là aussi bash sait faire aussi maintenant.
    - [^] # Re: bash parce bash
      
      Posté par freem le 13 avril 2018 à 11:25. Évalué à 3.
      
      Ceci dit, bash a aussi une complétion intelligente, et elle est activée
      
      Exact, mais franchement, elle n'a rien a voir avec celle de zsh niveau puissance… Ceci dit, celle de bash à le mérite de ne pas avoir besoin de relancer le shell pour prendre en compte l'installation d'un logiciel, contrairement à celle de zsh (ou du moins, je n'ai pas réussi à configurer zsh pour que ça fonctionne).
      - [^] # Re: bash parce bash
        
        Posté par Michaël (site web personnel) le 13 avril 2018 à 13:48. Évalué à 2.
        
        Exact, mais franchement, elle n'a rien a voir avec celle de zsh niveau puissance…
        
        Et encore tu es poli: comparer les deux n'a à moin avis presqu'aucun sens.
        
        contrairement à celle de zsh (ou du moins, je n'ai pas réussi à configurer zsh pour que ça fonctionne).
        
        Il suffit de demander rehash pour que le shell ZSH reconstruise son hash des commandes.
        
        [^] # Re: bash parce bash
        
        Posté par moi1392 le 14 avril 2018 à 10:45. Évalué à 3.
        
        Je peux avoir des exemples ? parce que moi, qui n'utilise pas zsh, mais qui ait un collègue qui l'a, ai remarqué au moins une dégradation de performance nette : l'auto complétion des cible de compilation ninja quand il y en a beaucoup (pareil avec make, mais c'est moins flagrant)
        Dans le projet de ma boite (un très gros logiciel avec plein de libs, plugins, … qui compile tout d'un coup), bash me complète mes cibles en 2/3 secondes, alors que zsh sur la machine de mon collègue, je l'ai ctrl+C au bout d'environ 10 secondes d'attente !
        Le second point, mais avec bash cette fois (je n'ai pas testé avec zsh), c'est que la complétion ne se fait pas quand l'extension ne corresponds pas au programme utilisé, et ce même s'il n'y a qu'une seule possibilité !
        exemple : tu sais que tu as une archivé zippée (et la commande file te confirme bien que c'est un zip), mais qui ne fini pas en .zip, l'auto complétion bash refuse de compléter, même quand c'est la seule possibilité, tu dois tout taper à la main…
        Est ce que zsh est meilleur sur ce point ?
        
        [^] # Re: bash parce bash
        
        Posté par freem le 16 avril 2018 à 14:18. Évalué à 2. Dernière modification le 16 avril 2018 à 14:20.
        
        Je peux avoir des exemples ?
        
        Chez moi (j'insiste, chez moi), bash ne semble pas pouvoir auto-compléter efficacement un script ./configure, zsh si. Idem pour make et cmake. Je n'ai jamais essayé ninja, donc…
        Sur les manpages également, il me semblait qu'il ne le faisait pas, mais apparemment ça a été ajouté. Par contre, dieux que c'est lent, et il faut double-tabuler…
        
        Ceci dit, il me semble qu'il y avait des trucs que je préférais sur l'auto-complétion de bash comparés à celle de zsh, mais je suis incapable de m'en souvenir.
        
        Et pour finir, ce genre de trucs doit sûrement être vachement modifié sur certaines distros, notamment Debian, vu que je doute que les chemins d'install soient uniformes en fonction des manpages et de la source des données (par exemples, j'en ai quelques unes dans /usr/local/… en plus de celles du système). Donc, ça peut être très différent chez toi ou d'autres.
        
        [^] # Re: bash parce bash
        
        Posté par Matthieu Moy (site web personnel) le 17 avril 2018 à 10:16. Évalué à 3.
        
        J'utilise d'habitude zsh donc mon bash n'est pas particulièrement customizé (Ubuntu 16.04). J'ai essayé :
        
        Chez moi (j'insiste, chez moi), bash ne semble pas pouvoir auto-compléter efficacement un script ./configure, zsh si.
        
        $ ./configure -- --bindir= --psdir= --cache-file= --quiet --config-cache --runstatedir= --datadir= --sbindir= --datarootdir= --sharedstatedir= [...]
        
        Idem pour make
        
        $ (echo foo1:; echo foo2:)>Makefile $ make foo foo1 foo2
        
        cmake.
        
        $ cmake - -A --help-manual --no-warn-unused-cli --build --help-manual-list -P -C --help-module --system-information --check-system-vars --help-module-list -T [...] $ cmake -D -DCMAKE_AR -DCMAKE_BUILD_TYPE -DCMAKE_COLOR_MAKEFILE -DCMAKE_CXX_COMPILER -DCMAKE_CXX_FLAGS [...]
        
        il me semblait qu'il ne le faisait pas, mais apparemment ça a été ajouté. Par contre, dieux que c'est lent, et il faut double-tabuler…
        
        Chez moi, il faut double-tabuler en cas d'ambiguité et c'est pas spécialement lent (il me sort quasi-instantanément Display all 10244 possibilities? (y or n)).
        
        À mon avis tu as un truc cassé dans ta config.
        
        J'aime bien zsh, mais de là à prétendre que la complétion intelligente de bash est incomparablement moins bonne, c'est peut-être pousser le bouchon un peu loin quand même.
        
        [^] # Re: bash parce bash
        
        Posté par freem le 17 avril 2018 à 10:39. Évalué à 2.
        
        Chez moi, il faut double-tabuler en cas d'ambiguité et c'est pas spécialement lent (il me sort quasi-instantanément Display all 10244 possibilities? (y or n)).
        
        Chez moi, il faut double tabuler à chaque fois que l'on veut afficher une liste avec bash, par exemple, avec zsh:
        
        mkdir /tmp/foobar /tmp/foorab cd /tmo/foo<tab>
        
        affiche la liste. Avec bash, il faut le faire 2 fois. Donc, quand on veut d'une part compléter jusqu'à l'ambiguïté, et d'autre part afficher la liste, il faut tabuler un total de 3 fois avec bash, 2 fois avez zsh (chez moi, et avec mes config, qui est custo uniquement pour zsh). Notes que je me dis que ça serait sympa que, dans le cas ou /tmp/foo n'existe pas, une seule tabulation affiche la liste. Ça serait probablement le plus intéressant, et aucun des deux ne semble le faire ici.
        
        À mon avis tu as un truc cassé dans ta config.
        
        Pas impossible, sauf que je ne modifie plus ma config bash depuis que j'utilise zsh.
        
        J'aime bien zsh, mais de là à prétendre que la complétion intelligente de bash est incomparablement moins bonne, c'est peut-être pousser le bouchon un peu loin quand même.
        
        J'ai pourtant lourdement insisté que c'est le comportement ici, que j'ai, et que ça peut varier en fonction de systèmes.
        Notamment, j'utilise Debian stable avec certains paquets rétroportés, le tout sur un système minimaliste.
        
        Ce que ça implique:
        
        déjà, si tu utilises un autre distro, tu as probablement des versions des softs plus récents;
        
        ensuite, il n'est pas impossible que Debian ait des patchs qui affectent l'auto-complétion;
        
        il est probable que certains paquets ne soient pas installés (le paquet bash-autocompletion l'a été quand j'ai testé, ceci dit) soit parce que pas listés dans les dépendances (depends, recommends ou suggests… j'ai déjà eu le cas sur des depends sur certains paquets debian) soit parce que je les considère inutiles dans mon usage (plus probable).
        
        Ce que j'ai dit, c'est qu'à l'époque ou j'ai lâché bash, sur les systèmes que j'utilisais c'était clairement le cas. J'ai aussi mentionné le fait que depuis au moins un comportement de bash s'est amélioré de ce point de vue.
        
        Si jamais je voulais mentionner un shell interactif de mauvaise qualité, ce n'est pas bash que je citerais, d'autant qu'il est largement suffisant pour la plupart des usages et plus simple à configurer que zsh.
        
        [^] # Re: bash parce bash
        
        Posté par Matthieu Moy (site web personnel) le 17 avril 2018 à 12:58. Évalué à 4.
        
        Avec bash, il faut le faire 2 fois.
        
        Dans la config par défaut, oui. Mais si tu cherches un peu, tu ne devrais pas mettre plus longtemps que moi à trouver show-all-if-ambiguous dans la config de bash.
        
        Notamment, j'utilise Debian stable
        
        J'ai reproduit les manips de mon message en oldstable (jessie), après avoir effacé ~/.bash*. Tout marche out-of-the-box aussi.
        
        J'ai pourtant lourdement insisté que c'est le comportement ici, que j'ai, et que ça peut varier en fonction de systèmes
        
        Moi, dans ton premier message, j'ai lu « franchement, elle n'a rien a voir avec celle de zsh niveau puissance », qui m'avait l'air un poil plus général que « je n'arrive pas à faire marcher la complétion chez moi » quand même …
        
        Tu te plains à la fois de la config par défaut qui n'est pas celle que tu voudrais, et de ta config qui ne fait pas quelque chose qui marche nickel par défaut, c'est un peu paradoxal.
        
        [^] # Re: bash parce bash
        
        Posté par freem le 17 avril 2018 à 13:51. Évalué à 3.
        
        Pas faux.
        
        [^] # Re: bash parce bash
        
        Posté par Matthieu Moy (site web personnel) le 17 avril 2018 à 15:04. Évalué à 2.
        
        Bon, après, on est d'accord que zsh powers quand même, hein ;-).
        
        [^] # Re: bash parce bash
        
        Posté par freem le 17 avril 2018 à 10:40. Évalué à 2. Dernière modification le 17 avril 2018 à 10:40.
        
        [edit]
        
        Zut, bug de connexion qui à causé un double post… à supprimer?
        
        [^] # Re: bash parce bash
        
        Posté par Michaël (site web personnel) le 17 avril 2018 à 21:05. Évalué à 2.
        
        Je peux avoir des exemples ?
        
        Dans mon cas, ma dernière expérience avec bash date d'il y a quelques années déjà alors ils ont certainement fait des progrès entre-temps, mais à l'époque où j'ai installé ZSH et oh-my-zsh sans plus de configuration qu'une liste de noms de plugins en plus des paramètres d'usine. Et tout d'un coup, magie: git complète, docker complète, git affiche sa branche dans le prompt, et toute plein de choses qui font du bien. Avec une historiques pas trop pourrie et des auto-complétions qui permettent de naviguer, c'était presque comme passer du phonographe au cinéma. ;)
        
        J'imagine que sur le papier les deux shells sont très proches en termes de possibilités: après-tout il s'agit juste de préparer les fonctions qui vont calculer les complétions possibles et cela n'a a priori pas grand chose avec le shell… n'empêche que à l'époque ou j'ai changé, les deux communautés n'avaient pas du tout produit les mêmes outils et c'était un petit travail en soi de mettre la complétion git dans bash: quand j'ai changé, tout d'un coup, tout était mieux qu'avant.
        
        [^] # Re: bash parce bash
        
        Posté par Matthieu Moy (site web personnel) le 18 avril 2018 à 10:11. Évalué à 4.
        
        ma dernière expérience avec bash date d'il y a quelques années déjà alors ils ont certainement fait des progrès entre-temps
        
        Donc tu es super bien placé pour écrire des choses comme « Et encore tu es poli: comparer les deux n'a à moin avis presqu'aucun sens. », hein …
        
        Et tout d'un coup, magie: git complète, docker complète
        
        cf. mon autre message, sur une Debian oldstable sortie il y a 3 ans, git complete aussi très bien. Docker existait à peine à l'époque donc sans grande surprise la complétion intelligente n'existait pas encore pour docker mais elle a bien sûr été ajoutée depuis.
        
        git affiche sa branche dans le prompt
        
        Sauf qu'on comparait la complétion intelligente, là. Et bon, le nom de branche dans le prompt, c'est pas dans la config par défaut de zsh (peut-être de oh-my-zsh par contre), et c'est pas comme si c'était compliqué à ajouter sous bash.
        
        Bref, perso, j'ai pas vu d'exemple pour supporter ton affirmation initiale, qui était pourtant bien affirmative …
        
        Encore une fois, j'adore zsh, mais faudrait peut-être se renseigner un peu avant de pourrir bash sans le connaître.
# Longtemps CSH

Posté par Michaël (site web personnel) le 12 avril 2018 à 07:44. Évalué à 3.

Il y a longtemps je croyais faire le cackou en tapant des commandes hyper-longues. Et puis un jour je me suis rendu compte que c'était idiot et qu'il fallait beaucoup mieux préparer un script hideux plutôt qu'une ligne de commande hideuse. Pour me rééduquer en quelque sorte je suis passé à CSH, shell avec lequel je ne sais quasiment rien faire. J'avais quand-même préparé une customisation sympa.

Depuis quelques temps j'utilise le ZSH avec les configurations “oh my zsh” tout en gardant ma bonne habitude de ne rien faire de très compliqué en ligne de commande.
# Et xonsh ?

Posté par azmeuk (site web personnel) le 12 avril 2018 à 09:04. Évalué à 8.

Pour écrire du python tout le temps ?
# Fish parce que recherche dans l'historique

Posté par Nicoco (site web personnel) le 12 avril 2018 à 13:00. Évalué à 3.

Je suis passé à fish depuis peu et j'en suis très content.

La principale raison est qu'avec bash, je commence à taper quelque chose, puis je suis plus sûr de la syntaxe, alors je fais CTRL+R, puis là en fait ça fait n'importe quoi parce qu'il fallait tout que j'efface avant, puis ça m'énerve, et du coup je mange des bébés chatons.

Tout ces problèmes ont disparu grâce à fish.

Après il faut avouer que j'ai une utilisation très basique et que j'aime bien les couleurs aussi.
- [^] # Re: Fish parce que recherche dans l'historique
  
  Posté par freem le 12 avril 2018 à 16:16. Évalué à 3. Dernière modification le 12 avril 2018 à 16:17.
  
  du coup je mange des bébés chatons.
  
  .
  
  Tout ces problèmes ont disparu grâce à fish.
  
  Parce que le caviar c'est meilleur que les chatons?
# Cygwin

Posté par Lucas-C (site web personnel) le 13 avril 2018 à 16:04. Évalué à -3.

ça n'a pas encore été mentionné alors je l'ajoute :
personnellement j'utilise Cygwin sous Windows
- [^] # Re: Cygwin
  
  Posté par J Avd le 13 avril 2018 à 23:48. Évalué à 5.
  
  🤔
  Ça n'a rien à voir… Dans cygwin tu utilises quel shell ?
  
  "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
# Dash

Posté par Liorel le 13 avril 2018 à 16:06. Évalué à -2.

c'est bash, souvent parce-que c'est par défaut sur les distributions que j'utilise (Mageia & Debian)

Bash a toujours été le shell par défaut de toutes mes distros

C'est fou le nombre de gens qui croient utiliser bash par défaut, alors que sur Debian et ses dérivées, c'est généralement dash.

Ça, ce sont les sources. Le mouton que tu veux est dedans.
- [^] # Re: Dash
  
  Posté par jvms le 13 avril 2018 à 16:21. Évalué à 5. Dernière modification le 13 avril 2018 à 16:23.
  
  Le shell interactif par défaut ça reste bash. Dash c'est uniquement pour interpréter les scripts commençant par #!/bin/sh qui avant étaient interprétés par bash.
  
  Mais pour un usage interactif, personne n'utilise dash, car ce n'est pas son rôle !
  - [^] # Re: Dash
    
    Posté par Renault (site web personnel) le 13 avril 2018 à 16:26. Évalué à 7.
    
    Mais je ne comprends pas, je croyais que c'était du Dash 3 en 1 !
    - [^] # Re: Dash
      
      Posté par Maclag le 14 avril 2018 à 03:52. Évalué à 5.
      
      J'ai un horrible doute:
      Si Dash est un terminal 3 en 1, est-ce que ça veut dire que Mir avait un terminal intégré dans une version Express??
      
      ---------> [ ]
      - [^] # Re: Dash
        
        Posté par freem le 16 avril 2018 à 14:22. Évalué à 2.
        
        Non, puisque ce ne sont pas des terminaux :)
      - [^] # Re: Dash
        
        Posté par Shunesburg69 le 17 avril 2018 à 14:07. Évalué à 1.
        
        Tant que vous faites pas de blague avec Omo, sinon il va y avoir des problèmes…
        Ni avec Ariel d'ailleurs sinon gare aux nageoires.
- [^] # Re: Dash
  
  Posté par Olivier LAHAYE (site web personnel) le 17 avril 2018 à 16:53. Évalué à -2.
  
  DASH c'est une horreur qui respecte meme pas les dernières avancées posix.
  Et c'est par défaut dans dracut. Heureusement on peut bloquer le module dash pour se retrouver avec bash.
  Franchement y'a même pas ${VARIABLE/search/replace}
  En tand que développeur de SystemImager, je peux vous dire que dans les hooks de dracut, c'est infiniment plus cool d'avoir bash que dash. Pour moi, dash ça reste une lessive point barre.
  DASH, c'est comment réinventer la roue en moins bien. C'est du bash lite. dash, le truc qui sert strictement à rien.
# l'ergonomique fish

Posté par arnodevo le 13 avril 2018 à 16:53. Évalué à 1.

Quel bonheur de ne plus avoir à taper

cd /home
cd ..

mais juste

/home
..

les suggestions qui apparaissent au fur et mesure qu'on tape une commande en se basant sur l'historique <3
Sans oublier un simple tab et la liste des options de la commande tapée qui apparaît <===3

essayé si vous avez l'occasion pour moi c'était comme passer d'un clavier basique à un clavier à touche mécanique niveau différence de confort
- [^] # Re: l'ergonomique fish
  
  Posté par raphj le 25 avril 2018 à 11:02. Évalué à 1.
  
  J'ai tout ça avec ma configuration de zsh (et oh-my-zsh), qui a été pas mal inspirée par fish (cette configuration, pour moi, c'est bash avec des couleurs et les fonctionnalités de fish).
  
  J'imagine que l'intérêt de fish sur zsh, ou de zsh sur fish, est la différence de syntaxe.
  
  Je rajouterais la coloration syntaxique, fonctionnalité très confortable de ces deux shells dont l'absence m'est devenue très pénible.
  
  Quelqu'un utilise xonsh, ce shell qui mélange shell et Python ?
# ca dépend de l'OS

Posté par xylphute le 13 avril 2018 à 21:08. Évalué à 0.

Habitué à bash sous linux, j'utilise(ais) tcsh sous IRIX et NetBSD. Je ne pousse pas assez loin en shell pour vraiment privilégier l'un plutôt que l'autre.
# Xkcd

Posté par J Avd le 13 avril 2018 à 23:50. Évalué à 3.

Ok donc personne n'utilise les papillons… #déçu

"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
- [^] # Re: Xkcd
  
  Posté par freem le 16 avril 2018 à 14:24. Évalué à 2. Dernière modification le 16 avril 2018 à 14:25.
  
  T'abuses, t'aurais pu mettre le lien qui va bien quand même.
  
  À moins que ça ne soit un usage détourné du SOI pour faire auto-compléter par un autre de linuxfr?
# QSH

Posté par goernil le 15 avril 2018 à 13:50. Évalué à 1.

En ce moment en utilisation pro, c'est QSH, le shell sur AS400/iSeries/i5/OS. Rien de particulier, c'est un shell UNIX assez basique. Le plus bizarre c'est que y'a pas de complétion par TAB, car on utilise un terminal 3270 passif

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.