Forum Programmation.shell Fonctions et alias de même noms, et surcharge d'alias

Posté par (page perso) . Licence CC by-sa
Tags :
3
5
août
2013

Bonjour,

J'ai deux questions à propos du shell sous GNU/Linux (bash ou zsh).

==> Si un alias et une fonction de même nom existent, comment savoir laquelle sera appelée ?
Ex :

alias rr='echo Hello'
rr () { command echo Hello "$@"; }

Dans ce cas, c'est ennuyeux avec zsh : à la définition de la fonction rr, le nom est remplacé par l'alias, et c'est echo qui va être remplacé par la fonction définie… (et donc, rr world renvoie Hello Hello world).

==> Le but c'était surtout de savoir s'il était possible d'empêcher plusieurs choses :

  • la définition d'une fonction dont le nom existe déjà en tant qu'alias ;
  • la redéfinition d'un alias existant.
  • # which

    Posté par . Évalué à 1.

    bon avec bash
    which permet de savoir si ce qui est exécuté est un binaire ou un alias (pas les fonction shell, mais si c'est ni l'un ni l'autre…)

    which grep
    alias grep='LANG=fr_FR grep --exclude="*.svn*" --color'

    le alias est interprété par le shell avant toute exécution par exemple un ls grep chez moi fera

    ls: option non reconnue « --exclude=*.svn* »

    pour empêcher le remplacement pas le shell il suffit de le précéder pas un \ ls \grep
    ls: grep: Aucun fichier ou répertoire de ce type

    pour le reste, je pense que la réponse a tes deux question est non ;)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: which

      Posté par (page perso) . Évalué à 2.

      Merci pour l'oblique inversée !

      Je peux maintenant voir que l'alias est prioritaire par rapport à la fonction (which/type ne voient que l'alias si les deux sont définis. Une fois unalias rr fait, la fonction est bien vue, et exécutée.)

      Dans zsh, ls grep ne donne pas du tout la même chose, puisque le grep n'est pas remplacé par son alias à l'exécution. En effet, dans zsh, les alias ne le sont, qu'en début de ligne, à moins de définir l'alias comme global.

      Merci quand même pour ta réponse.

    • [^] # Re: which

      Posté par . Évalué à 1.

      Un alias n'est évalué que si la commande commence par cet alias, pas s'il est au milieu :

      % alias foo=bar
      % ls foo
      ls: impossible d'accéder à foo: Aucun fichier ou dossier de ce type
      

      En revanche, zsh permet d'évaluer certains alias n'importe où dans une commande, en les déclarant avec alias -g (pour global).

      • [^] # Re: which

        Posté par . Évalué à 1.

        ce n'est pas le cas avec mon bash, l'exemple que j'ai donné est sous GNU bash, version 4.1.2

        chez moi :

        alias foo=bar
        ls foo
        ls: impossible d'accéder à bar: Aucun fichier ou dossier de ce type

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: which

          Posté par . Évalué à 2.

          Alors c'est un bug que vous devez signaler, car ça ne suit pas la norme des shells POSIX comme j'ai posté plus haut. Par ailleurs, mon bash 4.2.45 n'a pas ce comportement.

          • [^] # Re: which

            Posté par . Évalué à 2.

            Bug qui est assez chiant au demeurant, l'usage de man est rendu assez technique ;), mais avec le \ on s'en sort .

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Zsh

    Posté par . Évalué à 4.

    Les alias et les fonctions sont deux concepts différents. Le premier est utilisé lors de l'expansion de la ligne de commande (forcement d'abord), le second lors de l'exécution.

    http://zsh.sourceforge.net/Doc/Release/Expansion.html

    La question devient plus intéressante lorsqu'il s'agit de savoir dans quel ordre sont exécutés les builtins, fonctions, exécutables. Probablement dans cet ordre, mais je ne suis pas capable de trouver la réponse claire dans la doc.

    Il est aussi possible d'utiliser where ou whence -a pour avoir la liste des commandes correspondantes, et l'ordre de sélection.

Suivre le flux des commentaires

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