Nouvelle version majeure de bash

Posté par  . Modéré par Florent Zara.
Étiquettes :
0
2
août
2004
Ligne de commande
La version 3.0 de l'interpréteur de commandes du projet GNU apporte un nombre d'améliorations et de nouveautés assez impressionnant, tant pour le gourou que pour le débutant découvrant la ligne de commande:

- L'intégration de l'infrastructure d'internationalisation GNU gettext et libintl
- Un débogueur intégré (à invoquer via l'option --debugger)
- de nouveaux built-ins, rendant plus facile la manipulation de dates et des tableaux
- le support des expressions régulières dans les structures de test

D'autres choses encore sont à découvrir dans l'épais changelog.

Si Bash n'a pas toutes les fonctionnalités offertes par d'autres shells comme zsh (bien qu'il tende à s'en inspirer par moment), il n'en est pas moins un interpréteur de commande rapide et efficace, dont on est sûr de trouver une copie pour n'importe quel système *nix.

Souhaitons que sa francisation prochaine lui apporte de nouveaux utilisateurs...

Aller plus loin

  • # Faute dans le titre

    Posté par  . Évalué à 4.

    Il me semble que projet devrait être au singulier dans le titre, nan ?

  • # fuite un jour, fuite toujours

    Posté par  . Évalué à 10.

    toujours des fuites à la noix...

    - prendre son bash
    - taper '$(seq 1000000)' (ou moins si vous avez pas 100Mo à filer à bash)
    - sortir son top et constater le résultat

    bon, c'est pas tout, faudrait que j'envoie un rapport de bugs, je savais même qu'il y avait un site officiel, je pensais que c'était comme les *-utils, un bordel sans nom, des machins ça et là ...

    c'est un bon cru ce bash 3, la syntaxe {1..10} se faisait cruellement attendre.

    • [^] # Re: fuite un jour, fuite toujours

      Posté par  . Évalué à 3.

      Je ne connaissais pas, mais c'est assez marrant.
      Non seulement, ca prend 100% du CPU, mais en plus ca bouffe toute la mémoire.
      Et cela s'arrête lorsque bash n'arrive plus à allouer de mémoire.
      D'ailleurs, je ne comprends pas pourquoi, le processus s'arrête alors qu'il me reste encore 400Mo de swap de libre.
      Quelqu'un pourrait m'expliquer?

      • [^] # Re: fuite un jour, fuite toujours

        Posté par  . Évalué à 5.

        - seq mange du CPU, c'est normal, il fait son travail, il génére une liste de nombres (une séquence). Il faut donc du CPU, et de la RAM pour que bash stocke cette séquence textuelle. Le problème, c'est que sur une erreur, il libère pas, donc ça fuit.
        - après ça plante s'arrête sans doute à cause d'une limitation de bash.

        Bref le problème existe et peur certainement en révéler d'autres.

        • [^] # Re: fuite un jour, fuite toujours

          Posté par  . Évalué à 3.

          ça marche pas, votre truc ... Du moin, pas chez moi:
          Il genere sa liste de nombre puis s'arrette.
          La consomation CPU ses situe entre 10 et 15 %, pour 2MO de memoire.
          ( Mandrake 10.0 officiel sur athlon 2500+/ 512Mo. )

          • [^] # Re: fuite un jour, fuite toujours

            Posté par  . Évalué à 3.

            chez moi ça marche car tant que ce bash est lancé il continue de bouffer les 100Mo. Par contre si je relance plusieurs fois la commande ça n'en bouffe pas plus!
            Mdk Cooker

            ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: fuite un jour, fuite toujours

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

            Je pense que ce qu'il faut constater, c'est une fuite mémoire : tu regardes ta RAM free (avec l'outil du même nom) avant et tu regardes ta RAM free après : tu devrais voir une différence notable.

            N'importe quel programme est censé libérer la mémoire qu'il a demandé au système durant son exécution. Mais là, apparemment, il le fait pas (enfin, je dis ça, j'ai pas testé, moi)

            • [^] # Re: fuite un jour, fuite toujours

              Posté par  . Évalué à 1.

              ca n'est pas une fuite de memoire.
              contrairement a la libc4, les libc5 et libc6 ne rendent pas la memoire liberee par free() au systeme mais la conserve dans leur pool pour de futures allocations de memoire.

              ce comportement est genant lorsqu'un programme alloue ponctullement une grande quantie de ram

              • [^] # Re: fuite un jour, fuite toujours

                Posté par  . Évalué à 2.

                alors pourquoi sur

                for(;;)
                char *p;
                char c [100];
                p = malloc(100*1024*1024);
                gets(c);
                free(p);
                gets(c);
                }

                ca marche parfaitement (et meme si l'on rajoute une boucle qui ecrit dans la memoire allouer)

                et pourquoi sur dash pas de pb aussi ?

          • [^] # Re: fuite un jour, fuite toujours

            Posté par  . Évalué à 3.

            Je suis du même avis... Je ne constate pas le défaut.
            La consommation du CPU était aux alentours de 70%-80% parce qu'il y a des processus concurrents, le partage du temps est impeccable...
            La RAM est bouffée à hauteur de 100Mo en effet, mais est libérée...
            Pas de plantage...

            - Debian Sid,
            - bash à jour,
            - kernel 2.6.7 perso mais non patché (sauf pour NVidia),
            - 512Mo de RAM,
            - CPU P4 1,6GHz

            La vérité est ailleurs :)

            • [^] # Re: fuite un jour, fuite toujours

              Posté par  . Évalué à 4.

              chez moi ca marche (debian sid, 2.6.7 avec bash 3 et bash 2.05):

              $ ps v && $(seq 1000000) || ps v
              PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
              4134 pts/9 Ss 0:00 0 589 3886 1732 0.1 -bash
              4143 pts/9 R+ 0:00 0 61 2270 672 0.0 ps v
              -bash: 1: command not found
              PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
              4134 pts/9 Rs 0:08 0 589 105798 103644 9.9 -bash
              4153 pts/9 R+ 0:00 0 61 2270 672 0.0 ps v

              • [^] # Re: fuite un jour, fuite toujours

                Posté par  . Évalué à 2.

                Pareil, mais ce que je ne comprends pas c'est que ça ne marche qu'une fois (il va pas bouffer plus de mémoire si tu le refais). C'est bizarre pour une fuite ça.

                • [^] # Re: fuite un jour, fuite toujours

                  Posté par  . Évalué à 1.

                  ouai, il l'a révé sa fuite, sa passe très bien chez moi et j'ai du rajouter un 0 pour que ça passe pas ... et apres la mémoire est très bien libéré, elle l'est tellement bien que j'en ai plus de libre apres avoir exécuté la commande qu'apres avoir démarré le système =)

                  • [^] # Re: fuite un jour, fuite toujours

                    Posté par  . Évalué à 2.

                    Hum, m'est d'avis que vous devriez regarder du côté du cache mémoire de votre OS favori :)

                    Pour info un free ne libère pas la mémoire, il dit juste "je n'ai plus besoin d'elle" et si le même programme redemande la mémoire, il la retrouvera en général dans le même état si la charge est très faible...

                    M'enfin, ça demande vérification tout de même.

                    Caeies, mes 2cts

                    • [^] # Re: fuite un jour, fuite toujours

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

                      Voici un petit programme qui réserve et libère de la mémoire, pour vérifier donc 8-)

                      Dans tous les cas l'appel à la commande free renvoie "quasiment rien de libre" sur toute machine Linux ayant tourné plus d'1/2 journée. La politique de Linux est d'utiliser un max de ram pour le cache, pour "si jamais l'appli redemandait de la mémoire" etc. Rien de très surprenant à ce que Bash continue à faire semblant d'avoir besoin de 100 megs, je soupçonne que mon petit programme fasse pareil.

                      A sauver dans "mem.c", lancer avec "gcc mem.c -o mem && ./mem"

                      Je pense que ce vrai-faux problème de memory leak n'en est pas un, et que c'est tout bêtement lié à la façon dont le noyau gère la mémoire.

                      -------------8<----------------------------------------------------------------------
                      #include <stdlib.h>
                      #include <stdio.h>

                      #define N 10
                      #define S 10000000

                      void *my_malloc(int n)
                      {
                      void *ptr;

                      printf("Allocating %d bytes\n",S);
                      ptr=malloc(n);
                      if (ptr)
                      {
                      ((char *) ptr)[0]=' ';
                      ((char *) ptr)[n-1]=' ';
                      sleep(3);
                      }
                      else
                      {
                      printf("Failed...\n");
                      }

                      return ptr;
                      }

                      void my_free(void *ptr)
                      {
                      if (ptr)
                      {
                      printf("Freeing memory\n");
                      free(ptr);
                      }
                      }

                      int main(int argc, char *argv[])
                      {
                      void *ptr[N];
                      int i;

                      for (i=0; i<N;++i)
                      {
                      ptr[i]=my_malloc(S);
                      }
                      for (i=0;i<N;++i)
                      {
                      my_free(ptr[i]);
                      }
                      sleep(30);

                      return(0);
                      }
                      -------------8<----------------------------------------------------------------------

                    • [^] # Re: fuite un jour, fuite toujours

                      Posté par  . Évalué à 2.

                      tu peux alors expliquer pourquoi si l'on s'arrange pour bouffer juste toute la memoire dispo avec la commande, le shell devient inutilisable :
                      fork failed ...

                • [^] # Re: fuite un jour, fuite toujours

                  Posté par  . Évalué à 2.

                  sous dash :

                  ps v && $(seq 1000000) || sleep 5 && ps v
                  PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
                  18140 pts/4 SN 0:02 112 77 1470 576 0.4 dash
                  18182 pts/4 RN+ 0:00 160 61 2230 676 0.5 ps v
                  dash: 1: not found
                  PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
                  18140 pts/4 SN 0:04 112 77 1470 576 0.4 dash
                  18185 pts/4 RN+ 0:00 160 61 2230 676 0.5 ps v


                  sous bash

                  ps v && $(seq 100000) || sleep 5 && ps v
                  PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
                  18301 pts/5 SNs 0:00 349 589 5114 2648 2.0 -bash
                  18382 pts/5 RN+ 0:00 160 61 2230 676 0.5 ps v
                  -bash: 1: command not found
                  PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
                  18301 pts/5 SNs 0:01 349 589 14510 12044 9.4 -bash
                  18394 pts/5 RN+ 0:00 160 61 2230 676 0.5 ps v


                  A mon avis c'est bash qui essaye d'implemente un systeme de cache foireux ...

                  PS le sleep est pour permettre d'avoir des infos a jour
                  PS dash m'a pris quelques seconde pour faire le truc, j'ai du tue bash et recommencer avec moins de chiffres....

  • # Pas d'accord

    Posté par  . Évalué à 4.

    dont on est sûr de trouver une copie pour n'importe quel système *nix

    Connaissant les univers de deux grandes entreprises françaises, je n'ai jamais trouvé mon shell préféré sur leurs diverses environnments (allant de la prod au dev).

    Par contre ksh, là oui, on le retrouve partout.

    • [^] # Re: Pas d'accord

      Posté par  . Évalué à 5.

      Peut être parce que disponible ne veut pas dire installé.

      Ceci dit il est vrai que Bash est loin d'être le shell le plus répandu.

      M

      • [^] # Re: Pas d'accord

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

        HP-UX est fourni avec le Korn shell. Il y a à vrai dire assez peu de différences sauf que le bash est plus performant sur bien des points tel que la complétion de noms. À la décharge et au désespoir de Mr Korn, personne de semble vouloir prendre sa dernière version.
        Je pense qu'un shell doit rester un shell, si on continue à y ajouter des fonctionnalités, il faudra le doter qu'un compilateur ;-)

        • [^] # Re: Pas d'accord

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

          /usr/bin/emacs ? ;-)

        • [^] # Re: Pas d'accord

          Posté par  . Évalué à 3.

          «HP-UX est fourni avec le Korn shell. Il y a à vrai dire assez peu de différences sauf que le bash est plus performant sur bien des points tel que la complétion de noms.»

          Il faut quand même reconnaitre les qualitées de ksh, notement en matiere de programation: c'est une référence

          $ GET http://cnswww.cns.cwru.edu/~chet/bash/NEWS(...) | grep ksh

          v. New ksh93-like ${!array[@]} expansion, expands to all the keys (indices)
          d. `select' was changed to be more ksh-compatible, in that the menu is
          g. Added support for ksh93-like [:word:] character class in pattern matching.
          z. New [n]<&word- and [n]>&word- redirections from ksh93 -- move fds (dup
          l. The ksh-like `ERR' trap has been added. The `ERR' trap will be run
          g. There is a new ksh-93 style arithmetic for command:
          k. The ksh-93 ${!prefix*} expansion, which expands to the names of all
          d. ksh-88 egrep-style extended pattern matching ([@+*?!](patlist)) has been
          e. There is a new ksh-like `[[' compound command, which implements
          controls whether or not the ksh extended globbing feature is included.
          kkk. The ksh-like ((...)) arithmetic command syntax has been implemented.


          Et ça c'est que pour les modifications entre bash 2.05b et 3. Ça fait bien longtemps que bash et d'autres shell (zsh, ...) mettent en oeuvre des fonctionalitées de ksh88 et ksh93. Et ksh88 et ksh93, c'est pour 1988 et 1993 !!

          Mr Korn a plutot de quoi être fier ;-) En plus, ksh88 est libre (domaine public) et ksh93 est opensource, presque libre.

    • [^] # Re: Pas d'accord

      Posté par  . Évalué à 5.

      Il n'a pas dit sur n'importe quel système *nix. Mais pour. Il n'est pas forcément installé. Sur mon poste de travail (Linux) il ne l'est pas.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Pas d'accord

      Posté par  . Évalué à 1.

      oui mais quand on reprends du code ksh pour le mettre sous linux avec pdksh, il faut faire quelques adaptations.

      genre avec les "|read"


      echo $var1 |while read var2
      echo $var2
      done

      echo $var2

      $var2 redevient vide !! et pas sous AIX et HPUX par exemple.

    • [^] # Re: Pas d'accord

      Posté par  . Évalué à 3.

      C'est normal, puisqu'on (les sociétés impliquées dans Unix, les proprios commerciaux d'avant la venu du Messie ;-) a décidé que le shell de référence (à utiliser pour que ce soit portable entre leurs systèmes) serait le Korn Shell.
      D'où l'utilisation répandue du public domain korn shell (pdksh).

      • [^] # Re: Pas d'accord

        Posté par  . Évalué à 3.

        Oups!

        venuE

        while ( ! cervelle.isPuree() )
        {
        tete.frapper( leMur );
        }

    • [^] # Re: Pas d'accord

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

      Je crois que par défaut il n'est pas sur OpenBSD non plus. J'ai l'impression que Bash est plutôt spécifique au projet GNU (même s'il est portable et porté un peu partout).

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Pas d'accord

        Posté par  . Évalué à 3.

        Ça c'est pas étonnant, car Bash est sous GPL, et les *BSD essayent autant que possible de se passer de logiciel sous GPL pour la base du systeme.

  • # Ouah, une nouvelle version de bash ;-)

    Posté par  . Évalué à 0.

    Et en plus une release majeure...

    Est-ce que qqn sait quelles distros vont l'intégrer rapidement ?

    Par ex. Est-ce qu'on va bientôt le trouver dans cooker et dans sid ?

    Il me tarde de le tester, mais j'ai pas envie d'installer avc les sources... je veux pas casser mes jolies bases rpm ou apt...

  • # hors sujet?

    Posté par  . Évalué à 8.

    hors sujet? apprendre le bash pour les anglophiles:
    http://www.tldp.org/LDP/abs/html/(...)
    http://tldp.org/LDP/abs/(...)

  • # Avantage zsh ?

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

    > Bash n'a pas toutes les fonctionnalités offertes par d'autres shells comme zsh

    Mais que sont donc ces fameuses fonctionnalités offertes par zsh ?

    • [^] # Re: Avantage zsh ?

      Posté par  . Évalué à 4.

      L'avantage de zsh le plus parlant et son système de complétion.
      - Il permet la complétion avec les outils de gestion de paquets, apt-*, urpm*.
      - De pouvoir désigner un chemin de répertoire par quelques lettres uniquement. Par exemple "/h/s/Do/emacs" sera complété, s'il n'y a pas d'ambiguité, par "/home/serial/Documents/emacs".
      - Pas besoin de taper "cd" devant un nom désignant un répertoire accessible, il y va direct.
      - Et plein, d'autres je crois même que la complétion sur les clés GPG est supportée. Tout ceci est customisable bien sûr.

      • [^] # Re: Avantage zsh ?

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

        Bash permet la completion des commandes (apt, tar, make, etc.) pourvu que la description soit fournie :
        http://www.caliban.org/bash/index.shtml(...)

        • [^] # Re: Avantage zsh ?

          Posté par  . Évalué à 1.

          bash completion est tres lent alors que la completion dans zsh est ultra rapide

          la completion marche aussi pour emerge
          sinon genre tu tape "tar " il t'affiche la description de tt les option
          ensuite, il gere l'autocorrection

          genre : acetik@quanta ~ % sl
          zsh: correct 'sl' to 'ls' [nyae]?

          • [^] # Re: Avantage zsh ?

            Posté par  . Évalué à 2.

            Je n'ai pas testé trop la completion de bash, mais en tout cas la completion de zsh génère beaucoup d'acces disques (la premiere fois, apres, il y a beaucoup de cache)
            Ca fait chier surtout quand nfs rame..

        • [^] # Re: Avantage zsh ?

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

          Bash permet la completion des commandes (apt, tar, make, etc.) pourvu que la description soit fournie :

          Oui bien sur ! Cependant, il m'arrive d'utiliser bash + bash-completion, et j'ai parfois la completion qui met plus de 10 secondes a arriver. Je crois qu'avec zsh, il y a un systeme de cache, qui permet d'eviter ces desagreables secondes d'attente.

          voir aussi le journal : https://linuxfr.org/~mat_/14767.html(...) qui parle de ca, et du fait que bash-completion n'est pas activé par defaut sur les distribs, car il prend trop de ressources, cf thread :
          https://linuxfr.org/comments/453772.html#453772(...)

          • [^] # Re: Avantage zsh ?

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

            J'ai jamais dit que c'était rapide :)

            Le nombre de fois ou je me suis fait avoir avec un
            $> man g

            Ceci dit, à l'utilisation (sans complétion sur les commandes) bash me semble plus rapide que zsh (au lancement et à l'usage).

          • [^] # Re: Avantage zsh ?

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

            Euh, bah avec mdk 10, il était activé par défaut sur mon laptop dès l'install. Mais ça dépend des packages que l'on choisit d'installer, d'après moi.

      • [^] # Re: Avantage zsh ?

        Posté par  . Évalué à 3.

        apt-get install zsh
        zsh
        find - #rien
        find -n #rien
        ^D
        bash
        find -name


        bon ça s'active comment cette completion qu'il y a dans bash sans rien faire ?

        • [^] # Re: Avantage zsh ?

          Posté par  . Évalué à 1.

          % autoload -U compinit && compinit

          si je ne m'abuse...

        • [^] # Re: Avantage zsh ?

          Posté par  . Évalué à 4.

          Avec zsh sous debian, un bon point de départ est le fichier : /usr/share/doc/zsh/examples/zshrc.gz

          il suffit de retirer le exit 0 en début de fichier, de le recopier dans son home en .zshrc et de RTFM un p'tit peu quand même ;-)

          comme pour bash:
          /usr/share/doc/bash/examples/startup-files/bashrc

          comme pas mal de programme d'ailleurs...

        • [^] # Re: Avantage zsh ?

          Posté par  . Évalué à 1.

          sous debian , source /etc/bash_completion donne la completion contextuelle pour une mirielle de commande.

          On notera également une amélioration majeure avec la version 3 : quand la completion contextuelle définie échoue, on retombe sur la completion classique.

          C'est très utile par exemple quand on veut lire une video avec mplayer, qui n'a pas d'extension ou une extension foireuse... avant on n'avait pas de completion du tout puisque rien ne correspondait à la complétion contextuelle définie.

      • [^] # Re: Avantage zsh ?

        Posté par  . Évalué à 4.

        Il y a aussi des caractères génériques plus puissants, par exemple 
          konqueror **/*.html
        pour voir le contenu de tous les fichiers HTML dans le répertoire courrant ou dans l'un de ses sous-répertoires. Sous Bash, on pourrait taper 
          konqueror `find -name "*.html"`
        ou (s'il y a des fichiers avec des caractères bizarres) 
          find -name "*.html" -print0 | xargs -0 konqueror
        Autre exemple, quand on a tout une ribambelle de fichiers dans une arborescence compliquée, on peut vouloir les mettre tous dans un seul répertoire puis effacer les répertoires désormais vides : 
          mv **/*(.) ./
  rm -rf */
        Toutefois, sur de très gros répertoires, ça peut être lent. De plus, on se heurte assez vite à la taille limite de la ligne de commande. Mais ça va beaucoup plus vite à taper.

    • [^] # Re: Avantage zsh ?

      Posté par  . Évalué à 1.

      zsh, c'est pas celui avec une complétion super-balaise, genre quand tu fais tab après avoir tapé le nom d'une commande, tu as les argument possible, fichiers ET *options*?

    • [^] # Re: Avantage zsh ?

      Posté par  . Évalué à 2.

      La complétion est tellement bien faite sous ZSH que tu n'arrêtes pas de taper sur la touche [TAB].

      Si jamais tu ne sais pas quoi taper dans ton terminal, essayes [TAB] ça te donneras peut être une idée ;o)

      • [^] # Re: Avantage zsh ?

        Posté par  . Évalué à 2.

        acetik@quanta ~ % tar
        A -- append to an archive
        c -- create a new archive
        f -- specify archive file or device
        t -- list archive contents
        u -- update archive
        v -- verbose output
        x -- extract files from an archive

        voila zsh ;)

        et au niveau de la vitesse, bof bof, c'est vrai que bash est un cran plus rapide, mais pour une demi seconde hein ....

        genre dans ssh, avec le parametre -l , il te sort la liste des utilisateurs sur ton poste.

        • [^] # Re: Avantage zsh ?

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

          genre dans ssh, avec le parametre -l , il te sort la liste des utilisateurs sur ton poste.

          Et si as configuré ssh pour ne plus avoir a tapper ton password, zsh complete aussi les fichiers de l'hote distant :

          $ scp plop remote_host:/home/acetik/[TAB]

          • [^] # Re: Avantage zsh ?

            Posté par  . Évalué à 1.

            Et si tu as installé bash_completion, bash te complète aussi les fichiers de l'hote distant, donc zsh ne gagne pas de 'point' la dessus.

            • [^] # Re: Avantage zsh ?

              Posté par  . Évalué à 2.

              Pour généraliser sur les possiblités de completion de bash, on peut dire que toutes les informations pouvant être obtenu par un script bash peuvent être utilisé pour la completion (à un ou deux points près. Bin oui, je ne connais pas exactement toutes les imppossiblités de bash-completion).

              Le tout étant de coder ces scripts.

            • [^] # Re: Avantage zsh ?

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

              _myhosts=(${=${${(f)"$(<$HOME/.ssh/known_hosts)"}%%[# ]*}//,/ })
              :completion:*' hosts $_myhosts

              ou alors tu compète la variable hosts
              donc zsh compète aussi les hosts
              deplus il gère les type mime, etc.
              Le mieux c'est quand même la completion à partir d'un appel à la command genre mplyer -aoc [TAB] il appel mplayer -aoc help, le parse et t'affiche toutes les options ;)

    • [^] # Re: Avantage zsh ?

      Posté par  . Évalué à 3.

      Moi je citerais aussi l'historique.
      En effet je trouve bien plus pratique le système zsh "je tape le début de ma commande puis flèche haut"(et je n'ai l'historique que de *cette* commande) que le <ctrl>+<r> de bash bien moins pratique.

      • [^] # Re: Avantage zsh ?

        Posté par  . Évalué à 6. 

        thomas@eusebe % grep history-search /etc/inputrc
"\e[5~": history-search-backward
"\e[6~": history-search-forward
        Avec ça, j'ai PgUp et PgDown pour faire mes recherches dans l'historique en fonction du début de ma ligne. Ça fait effectivement parti des nombreuses choses à régler pour rendre bash confortable.

      • [^] # deux autres petites commandes

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

        tant qu'on y est, deux commandes dont je n'ai pas souvenir sous bash (mais je ne suis pas expert)
        - le raccourci ** qui veut dire tout en dessous de ce répertoire:
        par exemple, echo /home/invite/**/*.pdf pour trouver tous les fichiers pdf dans l'arborescence /home/invite
        - l'historique de cd.
        cd -l donne une liste des répertoires précedemment visités et cd -5 va au répertoie numéroté 5

    • [^] # Re: Avantage zsh ?

      Posté par  . Évalué à 7.

      à noter la licence maison de ZSH
      ftp://nephtys.lip6.fr/pub/unix/shells/zsh/LICENCE.gz(...)

    • [^] # Re: Avantage zsh ?

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

      Je pense qu'avec ça tu trouveras réponse à ta question

      http://linuxfr.org/~grom/3921.html(...)
      http://linuxfr.org/2004/03/25/15827.html(...)

    • [^] # Puisqu'on en est aux comparaisons de shell

      Posté par  . Évalué à 2. 


      
<cri de guerre anti-troll>
      
BOUHHHHH!!!
      
Sujet sérieux malgré les apparences
      
</cri de guerre>


      Quelqu'un aurait des nouvelles sur le gars qui avait recodé un shell à partir d'un autre... de mémoire je crois qu'il utilisait un csh pour développer un zsh.
      Encore un ambitieux quoi!

  • # On peut voir ?

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

    Y'a pas de copie d'écran ??

    C'est nul ? Bon ok...

Suivre le flux des commentaires

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