- les tableaux associatifs
- le support du globbing
- le support du changement de casse dans la complétion
- une plus grande conformité avec POSIX
- la simplification des redirections
Pour conclure, cette nouvelle version de Bash redonne tout son attrait à ce shell par rapport à son concurrent ZSH
Aller plus loin
- Annonce de la sortie (7 clics)
- Sortie de la version précédente (4 clics)
- Dernière mise à jour de zsh (1 clic)
# GNU bash
Posté par Stéphane Thomas . Évalué à 8.
[^] # Re: GNU bash
Posté par Zulon . Évalué à 3.
[^] # Re: GNU bash
Posté par mekare . Évalué à 9.
[^] # Re: GNU bash
Posté par Sytoka Modon (site web personnel) . Évalué à -10.
On voit que tu n'as pas du chercher à faire une distribution stable pour dire cela.
Mais rien ne t'empêche d'aller te mettre sous sid. Il parait que c'est très stable aussi.
[^] # Re: GNU bash
Posté par JoeltheLion (site web personnel) . Évalué à 10.
[^] # Re: GNU bash
Posté par mekare . Évalué à 4.
[^] # Re: GNU bash
Posté par FantastIX . Évalué à 4.
Juste ma petite précision perso.
[^] # Re: GNU bash
Posté par Zulon . Évalué à 6.
[^] # Re: GNU bash
Posté par FantastIX . Évalué à 1.
Ou «Kamikaze» ;-)
[^] # Re: GNU bash
Posté par fleny68 . Évalué à 8.
GNU bash est juste le shell par défaut des utilisateurs, c'est nettement moins critique.
[^] # Re: GNU bash
Posté par Nonor . Évalué à 2.
Un foetus de troll s'est caché dans ce post merci de ne pas en tenir compte...
[^] # Dash
Posté par eastwind☯ . Évalué à 2.
[^] # Re: GNU bash
Posté par kikicnrv . Évalué à 3.
Les scripts d'initialisation dans /etc/init.d ont toujours la ligne #!/bin/sh dans Lenny et /bin/sh pointe sur /bin/bash.
De plus le paquet bash est marqué required quand le paquet dash est marqué optional.
Pour la lenteur :
J'ai utilisé dash pour l'init pendant un moment. J'ai décidé de revenir à bash pour diverses raisons : résultat, 0 sec de différence.
Je veux bien que dash soit plus petit mais je pense qu'il faut vraiment une vieille machine pour commencer à le sentir un petit peu.
Par contre il parait que dash est plus conforme POSIX.
(pour ubuntu je ne sais pas)
[^] # Re: GNU bash
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
# dpkg-reconfigure dash
[^] # Re: GNU bash
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
Anne Nicolas a clairement affiché la couleur en annonçant de nouvelles dates des versions RC et repoussant la version finale aux derniers jours du mois d'avril.
# Page wikipédia vide
Posté par Florent Fourcot . Évalué à 3.
[^] # Re: Page wikipédia vide
Posté par thedude . Évalué à 3.
http://en.wikipedia.org/wiki/Globbing
[^] # Re: Page wikipédia vide
Posté par Mouns (site web personnel) . Évalué à 3.
[^] # Re: Page wikipédia vide
Posté par Bozo_le_clown . Évalué à 4.
Parmi les nouveautés ...
le support du globbing
Ca existait pas les caractères génériques sous Bash ?
La news est un peu sibylline sur ce point
[^] # Re: Page wikipédia vide
Posté par Bozo_le_clown . Évalué à 4.
http://linuxfr.org/comments/1010061.html#1010061
Tourner 7 fois son clavier dans sa bouche c'est pas facile
[^] # Re: Page wikipédia vide
Posté par Anonyme . Évalué à 1.
N'empêche je me suis posé la même question.
# ROhhhhhhh
Posté par Littleboy . Évalué à 10.
Merde, on est déjà vendredi?
Plus sérieusement, avant de lancer ce genre de trolls, il serait peut-être opportun de faire une comparaison et un récapitulatif avantages/inconvénients de ces deux shells (ou a défaut un lien vers un tel comparatif).
[^] # Re: ROhhhhhhh
Posté par Maclag . Évalué à 8.
Ben c'est fait:
Bash est redevenu plus attrayant que Zsh, donc Bash c'est mieux!
En plus c'est vachement plus répandu sur les systèmes Linux, donc y'a pas photo hein!
A vendredi!!
[^] # Re: ROhhhhhhh
Posté par Jérôme Pinot (site web personnel) . Évalué à 10.
http://en.wikipedia.org/wiki/Comparison_of_computer_shells
Où l'on voit que c'est le PowerShell de MS Windows qui a le plus de fonctionnalités \o/
Le shell est un composant critique sur un système, notamment du point de vue de la sécurité. L'ajout de fonctions dans tous les sens et d'extensions propres incompatibles avec les autres interpréteurs de commande augmente la possibilité de bugs et de failles.
Imaginez une faille de sécurité dans bash, sachant que presque toutes les distributions Linux l'intègre par défaut...
La course à l'ajout de fonctionnalités n'est pas forcément une bonne chose. Si l'on veut faire des choses compliquées avec le shell, et bien on appelle sed, awk, perl, etc.
Bref, est-ce vraiment un progrès que bash, zsh, cash, trollsh fasse même le café ?
[^] # Re: ROhhhhhhh
Posté par Zulon . Évalué à 2.
[^] # Re: ROhhhhhhh
Posté par Frédéric Heulin . Évalué à 2.
Sinon concernant la compatibilité avec les autres shells, la compatibilité POSIX est été améliorée.
Moi ce que je préfère, c'est les shell-forward-word and shell-backward-word pour déplacer rapidement les arguments dans une ligne de commande et le autocd si c'est bien le même que zsh.
Un petit emerge et je teste ça !
[^] # Re: ROhhhhhhh
Posté par yannig (site web personnel) . Évalué à 4.
Oups, on est pas vendredi ...
[^] # Re: ROhhhhhhh
Posté par 2PetitsVerres . Évalué à 10.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: ROhhhhhhh
Posté par Jean-Max Reymond (site web personnel) . Évalué à 3.
Pour ma part, j'en suis resté aux fonctionnalités de zsh 1994 et pour les shells scripts, je démarre toujours par #!/bin/sh, histoire d'être bien compatible :-)
[^] # Re: ROhhhhhhh
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
[^] # Re: ROhhhhhhh
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
dpkg-reconfigure dash
[^] # Re: ROhhhhhhh
Posté par Bozo_le_clown . Évalué à 1.
Pour avoir l'équivalent d'une commande comme celle là avec python
Dir|ForEach {$_.Get_Fullname()}
ca sera plus verbeux, même avec ipython.
Récuperer un objet qui mappe le répertoire, énumerer son contenu ; puis pour chacun des fichiers de la liste le wrapper en objet fichier et obtenir son nom long ou toute autre méthode en fonction des besoins.
Tu ne disposes pas des fonctionnalité basique des shells comme le pipe.
Avec les shells classiques tu passes par des chaines de caractères et tu passes ton temps à manipuler des chaines ou des options de présentations.
Powershell permet les 2 de façon transparente car il peut récupérer des objets au lieu de chaînes de caractères. Ceci ouvre toutes les possibilités liées à l'introspection (à comparer au man). En plus ca évite les erreurs bêtes de manipulation de chaînes (pb lorsque la sortie de la commande evolue, ...)
[^] # Re: ROhhhhhhh
Posté par barmic . Évalué à 1.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ROhhhhhhh
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
En pratique, chaque mise a jour de java n'enlèva pas la précédente version de java sous Windows.
Mes postes sous Windows XP Pro ont si mes souvenirs sont bons :
.Net 1
.Net 2
.Net 3
.Net 3.5
C'est sur qu'avec quatre version, on peut faire des choses portables... et je ne sais même si je peux enlever une version sans tout casser.
J'ai des scripts perl qui ont dix ans et qui marche toujours sur la dernière version de Perl... Je n'ai jamais mis plus d'un interpréteur Perl sur une machine.
[^] # Re: ROhhhhhhh
Posté par Littleboy . Évalué à 1.
Le reste c'est des bibliotheques en plus (comme WPF & WCF). Tu n'as donc pas 4 CLR, mais 2 (1 par version majeure incompatible).
[^] # Re: ROhhhhhhh
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Désolé mais ta phrase doit avoir un mot en moins. Je ne comprends pas le sens.
Alors, OK, .NET 3.5 et .NET 3.0, c'est la même chose.
Il n'empêche, j'ai des machines avec trois version de .NET alors que je n'ai jamais eu de version d'UNIX avec deux version de Perl.
Certes, Perl6 sera sur ma machine en parallèle de Perl5 mais Perl6 est un autre langage et la communauté ne s'amuse pas tout les 4 matins a changer l'API.
Enfin, j'ai donc 3 machines .NET sur une partie de mes machines et je n'ai de la part de Windows aucune indication pour savoir si oui ou non je peux les enlever. Aucune gestion des dépendances et ainsi de suite.
Donc oui je suis nul et je l'assume mais le parc que je gère fonctionne depuis des années sans grave panne... et madame michu chez elle, il m'étonnerais qu'elle se débrouille mieux que moi ;-)
[^] # Re: ROhhhhhhh
Posté par Littleboy . Évalué à 2.
Ils ont numerote ca 3.0 et 3.5 "abusivement", parce que les fonctionnalites en terme de nouvelles libs sont importantes. Mais la compatibilite n'est pas cassee.
En fait ca revient a avoir de nouvelles libs dispo. Si tu ne les utilises pas, ton programme tournera chez quelqu'un qui n'a que la version 2.0.
Donc ca revient exactement au meme point qu'avec Perl 5 et 6.
Une image pour mieux visualiser ici:
http://www.codeproject.com/KB/cs/vcpart1/7.png
je n'ai de la part de Windows aucune indication pour savoir si oui ou non je peux les enlever. Aucune gestion des dépendances et ainsi de suite.
Oui, ca pue! Surtout si tes utilisateurs peuvent deployer eux-meme des applis. Generalement il y a tres peu d'applis utilisant encore la version 1.1, mais ca c'est malheureusement a toi de regarder "a la main" dans la liste des applis que tu deploies.
Le probleme se pose surtout en termes "Est ce que j'ai encore besoin de l'ancienne version 1.x?", parce que 2.0, 3 et 3.5 c'est les mises a jour d'une meme version sous le capot.
[^] # Re: ROhhhhhhh
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Enfin, c'est un peu fou ce que l'on trouve dans les clefs de registre 'ajout suppression de programme' sur .NET. Entre tes explications limpides et ses clefs, il y a un monde... Peut être faudrait-il que Microsoft embauches des linguistes pour nommer leur objet ;-)
[^] # Re: ROhhhhhhh
Posté par Littleboy . Évalué à 2.
[^] # Re: ROhhhhhhh
Posté par daemontux . Évalué à 2.
[^] # Re: ROhhhhhhh
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Bon comparativement :
ls | while read file; do basename $file; done
ils | ieval("_.abspath()")
Dir | ForEach{$_.Get_Fullname()}
Avec un bon vieux shell c'est 10 caractères de plus (dont deux espace pour la lisibilité), je me remettrais de l'horrible perte de productivité qu'est la saisie de 10 caractères. D'autant que si ma ligne commence à grossir, je vais faire un script dans un fichier, et si mon script devient gros je peux passer facile à du perl.
Bref à chaque problème, une solution adapté.
Un modèle objet dans la ligne de commande, pourquoi pas, mais je ne suis même pas sûr qu'il me servirait tellement. Vu que je ne m'amuse pas à faire 200 lignes de codes shell en interactif, auquel cas n'importe quel langage peut faire l'affaire dans un fichier texte.
Cela étant, tu auras peut être des exemples qui seront me montrer l'intérêt du modèle objet dans un shell intéractif par une utilisation quotidienne possible qu'il faciliterais grandement.
[^] # Re: ROhhhhhhh
Posté par Bozo_le_clown . Évalué à 1.
Rajoutes les commandes qui n'ont rien à voir avec l'OS mais qui ne sont là que pour pallier les limites de l'approche (syntaxiques if then done, .... mais aussi purement utilitaires genre yes , seq, xargs et autres sed, cut, awk )
ipython privilégie l'objet, les shells classiques le traitement par chaine.
Powershell prend le meilleur des 2 mondes.
Mais c'est vrai que c'est ce qui appuie bien la différence entre un noob et un geek. Linux ca se mérite hein.
[^] # Re: ROhhhhhhh
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Tu dois quand même apprendre des commandes non ? Par exemple le Dir dans l'exemple ci-dessus. Après si la complétion t'affiche la liste des méthodes applicable à ton objet, ça peu être sympa, c'est vrai.
ont la moitié n'ont pas les mêmes paramètres, sont redondantes entre elles, n'offrent pas une sortie cohérente, sortie qui peut changer entre versions de l'OS ou entre unices.
Oui enfin là, faut utiliser du POSIX et, au moins en théorie, ça devrait passer. Quelle garantie j'ai de trouver sur tous les OS un powershell compatible à celui avec lequel j'ai testé mon script ?
Rajoutes les commandes qui n'ont rien à voir avec l'OS mais qui ne sont là que pour pallier les limites de l'approche (syntaxiques if then done, .... mais aussi purement utilitaires genre yes , seq, xargs et autres sed, cut, awk )
Oui, donc je les rajoute et qu'est-ce que je suis censé en conclure ? Qu'est ce que l'OS vient faire dans cette histoire ? On parle bien de shells non ? Qu'importe l'OS qui tourne en dessous.
Je suis d'accord que le shell unix à ses limites (qui ne le serait pas?), c'est pour ça que pour des travaux plus conséquent, il plus facile d'utiliser un autre langage.
Je ne dit pas que l'approche du powershell n'est pas bonne, juste que je ne vois pas trop d'exemple de tous les jours ou ce serait super plus pratique comme CLI à me donner envie de jeter mon zsh.
Mais c'est vrai que c'est ce qui appuie bien la différence entre un noob et un geek. Linux ca se mérite hein.
J'avoue ne pas saisir le sens de cette remarque.
[^] # Re: ROhhhhhhh
Posté par Bozo_le_clown . Évalué à 2.
Oui, donc je les rajoute et qu'est-ce que je suis censé en conclure ? Qu'est ce que l'OS vient faire dans cette histoire ? On parle bien de shells non ? Qu'importe l'OS qui tourne en dessous.
C'est bien ce que j'ai écrit. Les shells classiques sont pollués avec un tas de commandes qu'il faut apprendre et qui n'ont aucun lien avec leur l'essentiel: interagir avec l'OS
C'est un surcout inutile pour ceux qui veulent obtenir le meilleur de leur système.
Avec Powershell, tu te limites à connaitre ton système (ce fameux Dir que tu cites) mais tu n'as pas besoin de ces pseudos commandes.
Mais c'est vrai que c'est ce qui appuie bien la différence entre un noob et un geek. Linux ca se mérite hein.
J'avoue ne pas saisir le sens de cette remarque.
Ce n'est pas une attaque personnelle, juste une petite pique aux vieux routards qui se reconnaitront
[^] # Re: ROhhhhhhh
Posté par psychoslave__ (site web personnel) . Évalué à 2.
D'accord, mais du coups tu te limites aussi aux fonctions de ton système et aux méthodes de tes objets. Où alors tu dois faire appel à d'autres commandes qui ne sont pas des «bases du système» et donc t'es dans la même situation qu'avec un shell unix, non ?
[^] # Re: ROhhhhhhh
Posté par Bozo_le_clown . Évalué à 2.
Un shell tu l'as dit n'a pas pour objectif d'être un langage généraliste mais de permettre d'interagir avec l'OS.
Là on a quelque chose de cohérent, propre qui fournit le strict nécessaire.
[^] # Re: ROhhhhhhh
Posté par barmic . Évalué à 1.
Je me fait un programme (C par exemple) et je voudrais parser sa sortie standard.
Ca se fait comment en power shell ? (je dis ça naïvement je ne m'en suis jamais servi).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ROhhhhhhh
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Et comme à chaque fois, la réponse est : « Donnes-nous la version robuste aux espaces dans les noms de fichiers » (et j'anticipe sur la réponse à la réponse : et la version robuste aux retours chariots dans les noms de fichiers ?).
Effectivement, écrire des trucs pas robustes, « quick and dirty » en bash, ça marche bien, mais quand il s'agit de faire des trucs qui marchent vraiment, toujours, partout, là, c'est une autre paire de manches.
[^] # Re: ROhhhhhhh
Posté par Étienne . Évalué à 2.
$ ls -1
toto tutu
toto?tutu
$ for i in *; do readlink -f "$i"; done
/tmp/test/toto tutu
/tmp/test/toto
tutu
Çà ne me parait pas insurmontable.
Étienne
[^] # Re: ROhhhhhhh
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Effectivement, quand on n'utilise pas le « | » du shell normal, on n'a pas de problème avec, mais ça ne répond pas vraiment à la question. Le jour où tu voudras traiter une liste de fichiers que tu ne peux pas obtenir par globbing, tu mettras une commande à la place du « * », et tu retombera dans les mêmes problèmes.
Ceci dit, perso, je n'utilise pas le fameux powershell, je suis sous zsh et j'en suis très content. Ce que j'écris en ligne de commande est en général très « quick and dirty », mais je m'en fout. Par contre, je ne compte pas le nombre de scripts que j'ai pu écrire et qui ne sont pas robustes à cause de ce genre de trucs.
[^] # Re: ROhhhhhhh
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
(c'est un classique)
[^] # Re: ROhhhhhhh
Posté par wismerhill . Évalué à 1.
(soit ce sera pris comme une option reconnue et il manquera le fichier, soit pas et ce sera une erreur d'option inconnue)
[^] # Re: ROhhhhhhh
Posté par psychoslave__ (site web personnel) . Évalué à 3.
/tmp/test% ls -1 -i278691 foo bar/
278690 foo
bar/
278689 -l foo bar
/tmp/test% for i in *; do readlink -f -- "$i"; done
/tmp/test/foo bar
/tmp/test/foo
bar
/tmp/test/-l foo bar
Voilà.
[^] # Re: ROhhhhhhh
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
(sinon, « for i in ./* » ou « for i in *; do blablabla "./$i"... » marchent aussi).
[^] # Re: Tableau comparatif
Posté par Stéphane Ascoët (site web personnel) . Évalué à -1.
[^] # Re: Tableau comparatif
Posté par daemontux . Évalué à 3.
[^] # Re: Tableau comparatif
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1.
[^] # Re: ROhhhhhhh
Posté par RB . Évalué à 3.
Bref dans l'article de Wikipedia, le powershell se démarque car il est basé sur un langage moderne et non pas forcément sur des fonctionnalités d'interfaces: globbing, completion. Les fonctionnalités d'interface sont plus importantes pour moi. Mais il est clair qu'un nouveau shell qui reprendrait les avantages interfaciques de bash/zsh et qui serait basé sur un langage moderne ne ferait pas de mal.
Par contre le powershell est limité a lui meme: il perd tous ses avantages si vous devez le "piper" avec une autre appli qui est pas en powershell, alors qu'en ayant un format textuel par defaut, on pipe naturellement entre programmes écrits en différents langages, ce qui a aussi son avantage.
[^] # Re: ROhhhhhhh
Posté par Zulon . Évalué à 2.
Pour moi c'en est un, et un pas mal puissant en plus.
[^] # Re: ROhhhhhhh
Posté par RB . Évalué à 1.
[^] # Re: ROhhhhhhh
Posté par Dr BG (site web personnel) . Évalué à 6.
En français ça donnerait « l'entuber »...
Ah...
[^] # Re: ROhhhhhhh
Posté par RB . Évalué à 3.
[^] # Re: ROhhhhhhh
Posté par reno . Évalué à 3.
Pas nécessairement: on pourrait faire un tuyau "intelligent":
- tuyau entre 2 programmes qui comprennent les objets? Ce sont des objets qui sont passés.
- tuyau depuis un programme objet vers un autre: conversion des objets en représentation textuelle (qui est un dénominateur commun quelque part), le tuyau se chargeant de demander aux objets de s'afficher en texte.
Par contre la conversion texte --> objet ne me semble pas faisable automatiquement..
[^] # Re: ROhhhhhhh
Posté par pasBill pasGates . Évalué à 1.
- tuyau entre 2 programmes qui comprennent les objets? Ce sont des objets qui sont passés.
- tuyau depuis un programme objet vers un autre: conversion des objets en représentation textuelle (qui est un dénominateur commun quelque part), le tuyau se chargeant de demander aux objets de s'afficher en texte.
C'est deja le cas dans Powershell.
[^] # Re: ROhhhhhhh
Posté par reno . Évalué à 2.
[^] # Re: ROhhhhhhh
Posté par - - . Évalué à 2.
et franchement, powershell et .net sont 2 tanks nucléaires totalement inutiles et complexes pour simplement dire à son serveur windows de créer des comptes et partager les gestionnaires d'impression...
je peux excuser la passion mais à un moment, faut en revenir à des outils efficaces pour le Travail qui paye la nourriture du mois.
(oui, c'est un ton pédant, mais la "sur-ingénierisation" des solutions de microsoft m'a vraiment dégoûté.)
[^] # Re: ROhhhhhhh
Posté par reno . Évalué à 2.
Pas seulement: sérialiser n'implique pas forcément que le résultat soit du texte, 'sérialiser en texte' je suis d'accord par contre.
>faut en revenir à des outils efficaces
Tu confonds simplificité et efficacité: le shell est loin d'être efficace ni en CPU, ni en temps de developpement:
- le fait qu'il ne soit pas compilé induit une fragilité aux erreurs de syntaxe
- l'utilisation du texte par défaut rend les scripts très fragiles aux changements, aux noms de fichiers baroque qui casse le script,etc.
Pour ce qui est de Microsoft, l'idée d'utiliser un shell qui se passe des objets et non du texte par défaut ne vient pas d'eux, ils en ont fait une implémentation c'est tout..
# autocd?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: autocd?
Posté par Jean-Max Reymond (site web personnel) . Évalué à 5.
sous bash, il y a des chances pour que ce soit identique
[^] # Re: autocd?
Posté par JoeltheLion (site web personnel) . Évalué à 4.
# « Support » du globbing ?
Posté par Matthieu Moy (site web personnel) . Évalué à 9.
Par contre, le globbing a été amélioré, d'après l'annonce, ** est (enfin) supporté comme zsh, pour pouvoir écrire des choses comme **/*.c pour dire « tous les fichiers *.c dans un sous-répertoire du répertoire courant ». Et ça, c'est LA fonctionalité de zsh qui tue, et c'est vraiment cool que bash s'y mette.
[^] # Re: « Support » du globbing ?
Posté par Amand Tihon (site web personnel) . Évalué à 10.
Je vois au moins deux autres fonctionnalités qui tuent et que j'utilise très souvent :
cd /u/l/bi[tab] pour compléter tout d'un coup en cd /usr/local/bin
vim =monscript qui remplace avantageusement vim `which monscript`, pour peu que le script soit dans le path, bien sûr.
Un autre comportement qui me fait préférer zsh à bash, c'est que le globbing de .* n'inclut pas . et .. Étant habitué à zsh, je me suis fait mordre très méchamment par bash en voulant effacer tous les fichiers et répertoires cachés : « Oh ben zut, j'ai effacé le répertoire parent avec. »
[^] # Re: « Support » du globbing ?
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
En plus, c'est hyper dangeureux. Pour ceux qui n'ont jamais testé, faites dans un machine virtuelle (ayant une copie de sauvegarde) dans un dossier quelconque
rm -rf .*
C'est effectivement fatal et débile.
[^] # Re: « Support » du globbing ?
Posté par dyno partouzeur de drouate . Évalué à 2.
Par contre, c'est pas forcément le cas sur les autres Unix et assimilés...
[^] # Re: « Support » du globbing ?
Posté par Sebastien MICHEL (site web personnel) . Évalué à 2.
[^] # Re: « Support » du globbing ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
[^] # Re: « Support » du globbing ?
Posté par Gauthier Libéral . Évalué à 2.
[^] # Re: « Support » du globbing ?
Posté par Maclag . Évalué à 7.
A contrario, tant que Bash 4.0 ne sera pas généralisé sur les distros, les utilisateurs de zsh ne reviendront pas l'utiliser, et quand il passera dans les versions stables des distros, les zshiens l'auront oublié... \o/
[^] # Re: « Support » du globbing ?
Posté par Bapt (site web personnel) . Évalué à 2.
Par contre pour ceux qui veulent migrer vers ZSH choisissez bien une distribution qui ne maltraite pas ses utilisateurs en packageant uniquement la version 4.2 qui est quand même ultra vieille alors que la 4.3 est parfaitement stable et plus agréable (notamment à cause de l'unicode)
[^] # Re: « Support » du globbing ?
Posté par Zulon . Évalué à 3.
[^] # Re: « Support » du globbing ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: « Support » du globbing ?
Posté par Zulon . Évalué à 2.
# active le menu pour toutes les applications dans tous les contexteszstyle ':completion:*' menu yes select
[^] # Re: « Support » du globbing ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: « Support » du globbing ?
Posté par Octabrain . Évalué à 1.
zmodload zsh/complistMENUSELECT=0
[^] # Re: « Support » du globbing ?
Posté par Octabrain . Évalué à 2.
[^] # Re: « Support » du globbing ?
Posté par Jean-Max Reymond (site web personnel) . Évalué à 1.
que dire du *(.) pour tout ce qui est du type fichier. 15 années d'utilisation et que du bonheur :-)
[^] # Re: « Support » du globbing ?
Posté par benoar . Évalué à 3.
[^] # Re: « Support » du globbing ?
Posté par Amand Tihon (site web personnel) . Évalué à 4.
En bash (3.x) :
$ ll */*.c
-rw-r--r-- 1 atihon tcs 0 fév 25 17:21 B/b.c
En zsh :
$ ll **/*.c
-rw-r--r-- 1 atihon tcs 0 fév 25 17:21 a.c
-rw-r--r-- 1 atihon tcs 0 fév 25 17:21 B/b.c
-rw-r--r-- 1 atihon tcs 0 fév 25 17:21 B/C/c.c
-rw-r--r-- 1 atihon tcs 0 fév 25 17:21 B/C/D/d.c
# les tableaux associatifs ?
Posté par Dabowl_92 . Évalué à 5.
bonne nouvelle
ah non flute, bash est pas installé par défaut sous aix
# éditeur multilignes
Posté par Vincent Lefèvre (site web personnel) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.