Sortie de GNU Bash 4.0

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes :
23
24
fév.
2009
GNU
Plus de quatre ans après la sortie de GNU Bash 3.0 (voir l'annonce sur LinuxFR), les développeurs du shell par défaut du projet GNU rendent publique une nouvelle version majeure. Parmi les nouveautés de cette version, on peut noter :

  • 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
La sortie de cette nouvelle version de Bash se fait conjointement avec la nouvelle version de readline, la bibliothèque GNU de lecture de ligne.

Pour conclure, cette nouvelle version de Bash redonne tout son attrait à ce shell par rapport à son concurrent ZSH

Aller plus loin

  • # GNU bash

    Posté par  . Évalué à 8.

    Et bien, c'est un gros morceau, bash est un des shell les plus utilisé. Dans combien de temps pensez-vous que les distributions l'intègrerons ?
    • [^] # Re: GNU bash

      Posté par  . Évalué à 3.

      Gentoo l'intègre déjà %
      • [^] # Re: GNU bash

        Posté par  . Évalué à 9.

        Pour Debian stable... quand Bash 5.0 sortira ?
        • [^] # Re: GNU bash

          Posté par  (site web personnel) . Évalué à -10.

          La stable vient de sortir ! Tu n'intègre pas un nouvelle version de bash au dernier moment et avant la sortie stable de ce shell !

          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  . Évalué à 4.

        Gentoo l'intègre, oui mais il est actuellement masqué (missing keyword) pour toutes les architectures supportées, ce qui signifie «à vos risques et périls». La version de bash supportée officiellement par Gentoo est la 3.

        Juste ma petite précision perso.
        • [^] # Re: GNU bash

          Posté par  . Évalué à 6.

          Bah, on utiliserait pas Gentoo si on était pas un peu téméraire :-'
          • [^] # Re: GNU bash

            Posté par  . Évalué à 1.

            Bah, on utiliserait pas Gentoo si on était pas un peu téméraire :-'

            Ou «Kamikaze» ;-)
    • [^] # Re: GNU bash

      Posté par  . Évalué à 8.

      Pour debian/ubuntu, bash n'et plus le shell utilisé par le processus d'init: trop lent. C'est Dash qui est utilisé.

      GNU bash est juste le shell par défaut des utilisateurs, c'est nettement moins critique.
      • [^] # Re: GNU bash

        Posté par  . Évalué à 2.

        Bash est "trop lent" pour Ubuntu ? :-D la blague

        Un foetus de troll s'est caché dans ce post merci de ne pas en tenir compte...
      • [^] # Dash

        Posté par  . Évalué à 2.

        Lave plus blanc !
      • [^] # Re: GNU bash

        Posté par  . Évalué à 3.

        Qu'entends tu par le processus d'init ?

        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  (site web personnel) . Évalué à 1.

      Bash4 sera très certainement présent dans Mandriva 2009.1 "Spring" qui sortira fin avril. Mais comme les nouvelles fonctionnalités n'intéressent que peu d'utilisateurs, la version 4 de bash ne devrait pas être la version nominale. La volonté affichée sur cooker est de faire une version aussi bien débuggée que possible encore mieux que la version 2008.1 qui était déjà une réussite.
      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  . Évalué à 3.

    Hum, j'étais intéressé pour savoir ce qu'étais le « globbing » afin de dormir moins bête ce soir, mais la page Wikipédia est inexistant sur le sujet.
  • # ROhhhhhhh

    Posté par  . Évalué à 10.

    Pour conclure, cette nouvelle version de Bash redonne tout son attrait à ce shell par rapport à son concurrent ZSH

    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  . Évalué à 8.

      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).

      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  (site web personnel) . Évalué à 10.

      >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).

      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  . Évalué à 2.

        On ne parle pas ici de "faire le café", mais de fonctionnalités bien utiles comme les globbing qualifiers (exit find... ou presque), un système de complétion cohérent, complet et personnalisable (et ça c'est pas indiqué sur Wikipédia)...
        • [^] # Re: ROhhhhhhh

          Posté par  . Évalué à 2.

          Surtout que la plupart de ces ajouts sont des fonctionnalités non activés par défaut et donc devront être ajouté par celui qui en a besoin (tant qu'à faire en mode interactif uniquement) et surtout désactivé au niveau système pour éviter le problème de failles justement.

          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  (site web personnel) . Évalué à 4.

        Perdu ! Tu as le shell python qui fait aussi bien que le PowerShell et en plus il est GPL. Au passage, j'ai des doutes sur la nécessité de certaine fonction dans le cadre de script shell. J'ai jamais trop vu d'administrateur Unix se prendre la tête avec des tableaux multidimentionnels, des paramètres nommés, de la programmation lambda, j'en passe et des meilleurs.

        Oups, on est pas vendredi ...
        • [^] # Re: ROhhhhhhh

          Posté par  . Évalué à 10.

          Tu n'as jamais vu d'administrateur utiliser une fonction de son shell que son shell n'a pas ? Surprenant.

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Re: ROhhhhhhh

          Posté par  (site web personnel) . Évalué à 3.

          le débat avait eu lieu vers 1994 sur zsh (ça ne nous rajeunit pas). Quand tout le monde trouvait nécessaire de souffler, le développeur principal s'était lancé dans les tableaux multi-dimensionnels, dédaignant les avis de ceux qui pensaient que c'était le boulot de awk.
          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  (site web personnel) . Évalué à 5.

            Attention, sur pas mal de distribs, /bin/sh est assez permissif (sous Debian, c'est un bash par exemple). Sur ces distribs, on peut écrire des scripts pas POSIX du tout et qui marcheront quand même ... jusqu'à ce qu'on passe sur une autre distrib (typiquement, j'alterne entre Debian et Ubuntu, et ubuntu a un dash fait pour être strict comme /bin/sh, donc mes scripts mal écrits n'y marcheront pas).
        • [^] # Re: ROhhhhhhh

          Posté par  . Évalué à 1.

          Dsl de te contredire mais il me semble que même avec ipython et pas python on est bien loin de powershell

          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  . Évalué à 1.

            Il faut utiliser .Net pour bénéficier de l'objet dans le shell (exit les petits script en perl, C, C++, les sorties de commandes classiques comme gcc, etc...)

            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  (site web personnel) . Évalué à 6.

              Enfin, je commence a en avoir un peu marre de .Net et de java. Soi-disant, c'était portable et tout et tout.

              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  . Évalué à 1.

                C'est sympa, mais ca serait mieux si tu savais un peu de quoi tu parles. .Net 3 et 3.5 utilisent tous les deux la CLR 2.0. Ca fait donc 2 versions (et les programmes pour 1 et 1.1 ne sont pas vraiment nombreux...).

                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  (site web personnel) . Évalué à 3.

                  > .Net 3 et 3.5 utilisent tous les deux la CLR 2.0. Ca fait donc 2 versions

                  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  . Évalué à 2.

                    .Net 3.0 et 3.5 tournent avec la meme machine virtuelle que .Net 2.0. Ils ne rajoutent que des bibliotheques en plus.

                    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  (site web personnel) . Évalué à 3.

                      OK, j'avoue que je gère le parc sans aucune passion pour .NET donc je contaste juste ce que je vois avec un regard un peu 'candide'. Donc merci pour tes explications.

                      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  . Évalué à 2.

                        C'est surtout les gars du marketing qui sont passes par la. Il suffit qu'ils debarquent pour que "Avalon" et "Indigo" se transforment en Windows Presentation Foundation et Windows Communication Foundation...
          • [^] # Re: ROhhhhhhh

            Posté par  . Évalué à 2.

            Avec iPython + ipipe : ils | ieval("_.abspath()") retourne le chemin absolu des fichiers. Arrête moi si je me trompe mais ça me semble similaire et pas vraiment plus verbeux non ?
            • [^] # Re: ROhhhhhhh

              Posté par  (site web personnel) . Évalué à 4.

              Oui enfin loin de moi l'idée d'encenser le powershell mais ce que tu donnes là c'est pas très parlant «ils», ça me parle moins que «dir». Est ce que toutes les commandes ont le mauvais goût de commencer par i ?

              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  . Évalué à 1.

                L'interêt de l'objet ? l'introspection qui me permet de connaitre rapidement ce que l'on peut faire sur un objet. Ca m'évite d'apprendre toutes les commandes unix qui pourront me servir et dont 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.
                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  (site web personnel) . Évalué à 3.

                  l'introspection qui me permet de connaitre rapidement ce que l'on peut faire sur un objet. Ca m'évite d'apprendre toutes les commandes unix qui pourront me servir


                  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  . É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  (site web personnel) . Évalué à 2.

                      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.

                      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  . Évalué à 2.

                        Tu peux tjs te créer tes commandes mais tu en as besoin de moins c'est tout.

                        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  . Évalué à 1.

                          Oui mais comment tu fait pour te créer des utilitaire à toi ?
                          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  (site web personnel) . Évalué à 1.

                C'est le genre d'exemples qui ressort à tous les coups quand on parle de shell objet.

                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  . Évalué à 2.

                  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 ?).

                  $ 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  (site web personnel) . Évalué à 1.

                    Là, on parlait du « | » du powershell.

                    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  (site web personnel) . Évalué à 1.

                      D'ailleurs, ta version n'est pas robuste non plus. Je te laisse trouver le nom de fichier qui la fera planter ;-).

                      (c'est un classique)
                      • [^] # Re: ROhhhhhhh

                        Posté par  . Évalué à 1.

                        N'importe quoi qui commence par un tiret?
                        (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  (site web personnel) . Évalué à 3.

                          Il faut utiliser «--» pour signaler que la suite ne comprends plus que des arguments et pas d'options.

                          /tmp/test% ls -1 -i
                          278691 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  (site web personnel) . Évalué à 1.

                            Donc, effectivement, trois tentatives suffisent pour écrire une ligne correcte en shell ;-).

                            (sinon, « for i in ./* » ou « for i in *; do blablabla "./$i"... » marchent aussi).
      • [^] # Re: Tableau comparatif

        Posté par  (site web personnel) . Évalué à -1.

        Ce tableau comparatif ne me semble pas pertinent. Déjà il associe "cmd" à Window$ alors qu'il n'est intégré qu'à la série "NT"... Et s'abstient de comparer les facultés de cet outil selon qu'il est lancé sous l'interface graphique ou en mode texte simple...
        • [^] # Re: Tableau comparatif

          Posté par  . Évalué à 3.

          Comment ça "en mode texte simple" ? À ma connaissance il n'y a pas de mode texte pur sous Windows, même quand on demande à lancer l'invite de commande en mode sans-échec elle est lancée dans une fenêtre.
      • [^] # Re: ROhhhhhhh

        Posté par  . Évalué à 3.

        Pour moi le shell n'est pas exactement un langage de programmation. Ce que je veux dire c'est qu'il n'a pas pour vocation de remplacer des langages plus complet lorsqu'il s'agit de faire des choses plus complexes. D'ailleurs a l'époque, une grosse partie des scripts étaient écrit en perl. Cette dépendance a perl a été supprimée car "un gros morceau" comme perl ne plaisait pas forcement comme composant de base d'un distro (en plus si l'utilisateur en voulait une version plus récente, il fallait faire de la cohabitation).

        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  . Évalué à 2.

          Franchement je sais pas ce qu'il vous faut pour faire un langage de programmation. Un langage qui permet de spawner de nombreux processus, de rediriger des flux entre ces processus et entre des fichiers, qui permet d'utiliser des tableaux (associatifs ou pas), qui combiné à des outils standards (comprendre "on les trouve sur toutes les machines, c'est des acquis") permettent l'emploi d'expressions régulières et autres joyeusetés, c'est pas un langage de programmation ?
          Pour moi c'en est un, et un pas mal puissant en plus.
          • [^] # Re: ROhhhhhhh

            Posté par  . Évalué à 1.

            Voulais dire "n'a pas forcément pour vocation d'etre un langage de programmation"
        • [^] # Re: ROhhhhhhh

          Posté par  . Évalué à 6.

          il perd tous ses avantages si vous devez le "piper"

          En français ça donnerait « l'entuber »...

          Ah...
          • [^] # Re: ROhhhhhhh

            Posté par  . Évalué à 3.

            traduction pouvant conduire a des quiproquos dans la vie courante :)
        • [^] # Re: ROhhhhhhh

          Posté par  . Évalué à 3.

          [[ Par contre le powershell est limité a lui même: 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. ]]

          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  . Évalué à 1.

            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.


            C'est deja le cas dans Powershell.
            • [^] # Re: ROhhhhhhh

              Posté par  . Évalué à 2.

              Interessant, je ne savais pas, merci pour l'info.
          • [^] # Re: ROhhhhhhh

            Posté par  . Évalué à 2.

            on appelle cela sérialiser

            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  . Évalué à 2.

              >on appelle cela sérialiser

              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  (site web personnel) . Évalué à 2.

    Est-ce que quelqu'un saurait me dire ce que fait la nouvelle fonctionnalité "autocd"? Je ne comprends pas la brève description, et google n'a rien révélé d'autre... Pourtant ça a l'air intéressant!
    • [^] # Re: autocd?

      Posté par  (site web personnel) . Évalué à 5.

      sous zsh, ça t'évite de taper un cd si tu mets un nom de répertoire. Par exemple, /etc suivi d'un retour chariot te fait aller dans le répertoire /etc
      sous bash, il y a des chances pour que ce soit identique
  • # « Support » du globbing ?

    Posté par  (site web personnel) . Évalué à 9.

    Le globbing a toujours été supporté par bash, non ? Le globbing, c'est juste le fait de pouvoir écrire *.c pour dire « tous les fichiers terminant par .c ».

    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  (site web personnel) . Évalué à 10.

      Je serais plus nuancé, c'est UNE fonctionnalité de zsh qui tue et je suis très heureux que bash l'intègre parce qu'il m'arrive d'être sous bash :)

      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  (site web personnel) . Évalué à 7.

        Il est clair que .* en bash donne aussi .. dans la liste et que c'est une grossière erreur qui traine. En effet, * ne donne pas les fichiers en . donc je ne vois pas pourquoi .* donne les fichiers en ..quelque chose.

        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  . Évalué à 2.

          Le rm de GNU, qui est normalement celui par défaut sur ta distribution Linux, te dira qu'il ne peut pas effacer . et .. ce qui t'évitera la déconvenue d'effacer tout /home quand tu fais un rm -r .* en root dans /home/user.

          Par contre, c'est pas forcément le cas sur les autres Unix et assimilés...
      • [^] # Re: « Support » du globbing ?

        Posté par  (site web personnel) . Évalué à 5.

        Ah, je ne connaissais pas tout ça. En revanche, pour moi, la fonctionnalité qui tue, c'est la complétion en-dessous de la ligne de commande. Ça évite de remplir le tampon de remontée du terminal de listes de complétion, comme avec Bash.
    • [^] # Re: « Support » du globbing ?

      Posté par  (site web personnel) . Évalué à 1.

      Monsieur est gourmet !
      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  . Évalué à 3.

      Bizarre, moi un simple */*.c va chercher pareil en zsh. Qu'apporte le fait de mettre **/*.c ?
      • [^] # Re: « Support » du globbing ?

        Posté par  (site web personnel) . Évalué à 4.

        Il apporte toutes les profondeurs d'arbo, y compris le répertoire courant.

        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  . Évalué à 5.

    si bash gère maintenant les tableaux associatifs, je vais pouvoir me passer de perl pour certains scripts :-)

    bonne nouvelle

    ah non flute, bash est pas installé par défaut sous aix
  • # éditeur multilignes

    Posté par  (site web personnel) . Évalué à 4.

    Toujours pas d'éditeur multilignes? zsh en a un depuis au moins 1995.

Suivre le flux des commentaires

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