Fish-shell: && ne fonctionne pas

|| serait aussi bien.

Je veux juste exprimer une opinion alternative.
'||' et '&&' sont les éléments de syntaxe, tandis que 'and' et 'or' sont des commandes simples. Cette approche est simple et propre.
Je pense que ce n'est pas une bonne idée d'introduire des éléments de syntaxe supplémentaires pour implémenter une capacité déjà existante.
C'est différent de bash, mais ça va.

Je voterais aussi pour avoir && et || car il s'agit d'un sucre syntaxique couramment utilisé et ce serait vraiment bien d'en avoir la facilité d'utilisation.

+1 à la suggestion de maxfl.

+1 à la suggestion de maxfl.

Ruby a également des mots-clés and et or .

+1

Je n'ai pas d'objection si quelqu'un veut s'en charger.

-1 à la mise en œuvre &&/|| et +1 à maxfl. Et je ne vois pas vraiment la raison pour laquelle il devrait être mis en œuvre. Ce n'est pas du sucre syntaxique, dans bash c'est juste la syntaxe et dans fish cette syntaxe n'existe pas. Ce serait aussi vraiment inutile car le sucre syntaxique comme ';or' prend exactement autant de frappes que '||'.

J'aime la simplicité des commandes and et or , mais un problème est qu'elles rendent les instructions if bizarres. Par example:

if begin ; [ a = b ] ; and [ c = d ] ; end
   ...

par rapport à

if [ a = b ] && [ c = d ]
    ...

Quelqu'un a des idées pour améliorer ça ?

if test a = b -a c = d # or [ ] syntax, but I didn't particularly liked it
    ...

Mais bien que cela fonctionne pour test intégré, cela ne fonctionne nulle part ailleurs. Supposons que les commandes internes a et b retournent true pour exécuter c et d . Ensuite, nous pourrions l'écrire comme ça.

and b
and begin
    c
    d
end

Ou avec la syntaxe de bloc et if .

if begin
        a
        and b
    end
    c
    d
end

Ou faire des conditions imbriquées.

if a
    if b
        c
        d
    end
end

Là encore, je ne sais pas à quelle fréquence ce hack est nécessaire, mais searchco.de dit que && est principalement utilisé avec test intégré (ou pour les effets secondaires).

Je ne sais pas vraiment si fish aurait besoin d'une autre syntaxe utile uniquement dans de rares cas. Cela ressemble déjà à [ , sauf que l'on a dû rester car c'est de toute façon binaire (juste comme test ). Cela ne semble pas particulièrement louche, mais c'est ici, car c'est binaire (contrairement à [[ que je suis content que fish ne supporte pas).

Avoir deux syntaxes (ou dans ce cas, même trois) serait plutôt déroutant. Quelle syntaxe dois-je utiliser ?

if a
    b
end

a; and b

a && b

Il semble que && soit le plus court, sauf que c'est la moitié de la vérité. Taper ;and prend exactement le même nombre de frappes (car & implique Shift). L'ajout de && encouragerait l'ajout d'une syntaxe supplémentaire (là encore, and est analysé de manière spéciale, car vous pouvez insérer des mots-clés comme begin après, et ils fonctionnent).

Le problème est que nous avons les syntaxes ; and et ; or - les nouvelles syntaxes donneraient l'impression d'être des doublons. Ils sont déjà en quelque sorte magiques (ce ne sont pas seulement une fonction de script shell qui vérifie la variable $status ), donc je n'aurais pas de problème s'ils étaient remplacés par && et || .

Je ne sais pas quoi penser. Je pense qu'il devrait y avoir une seule syntaxe pour le faire. J'aime ; and et ; or , mais je n'aurais pas de problème avec && et || , à condition que les anciennes syntaxes soient supprimées. Mais compte tenu de la rétrocompatibilité, je préférerais rester avec ; and et ; or . Peut-être que si begin était plus court (comme les accolades dans bash)... mais cela ne semblerait pas louche.

Pourquoi ne pas prendre en charge un [[ intégré comme le fait bash ? Ce serait plus rapide (voir : écho intégré) et il prendrait en charge && et || dans les [[ et ]] pour émuler le et/ou le comportement.

Parce que [[ n'est pas une commande réelle, elle n'existe que dans bash. Le problème est que [[ est comme [ (principalement), sauf qu'il a des règles d'analyse spéciales pour éviter les guillemets inutiles. Voir la loi d'orthogonalité et la loi de découvrabilité pour voir pourquoi ce n'est pas dans le poisson.

En fait, je suis presque sûr que [ n'existerait pas à cause de la loi de découvrabilité et de la loi d'orthogonalité, mais c'est le cas parce que c'est binaire dans /usr/bin . test est plus louche, car vous pouvez le découvrir en utilisant la complétion de tabulation. Mais bloquer les binaires serait plutôt arbitraire, alors autant l'implémenter en tant que fonction intégrée.

Par exemple, dans bash, [[ cite automatiquement toutes les chaînes.

[[ abc = $variable ]]

Mais cela n'est pas nécessaire dans les poissons car le comportement de division des espaces n'existe pas. De plus, il cite automatiquement && , || , < et > car c'est une fonction syntaxique. Dans le poisson, le && est -a , || est -o . < et > n'existent même pas.

Il a également l'opérateur =~ . Dans fish , vous pouvez utiliser quiet grep pour cela.

echo $ANSWER | grep -qE '^y(es)?$'

De plus, bash a l'opérateur < et > . Ils vérifient quelle chaîne est supérieure ou inférieure à une autre chaîne. C'est rarement utile.

Et, lorsque vous utilisez les opérateurs = et != , vous pouvez utiliser la syntaxe globale, tout comme vous utiliseriez des expressions régulières. Encore une fois, utilisez calme grep pour cela.

[[ abc = a* ]]

De plus, le [[ est défini comme ayant -e , -nt , -ot , -ef , et ! , mais fish les a déjà dans test intégré.

L'ajout de [[ ajouterait simplement un autre mot-clé, qui ne serait pas vraiment détectable et n'ajouterait pas vraiment beaucoup de fonctionnalités. La seule fonctionnalité intéressante est =~ , mais quiet grep (ou Perl) peut faire la même chose, sans ajouter de nouvelle syntaxe. De plus, nous ne devrions pas tout ajouter à shell. Je ne pense pas que nous ayons besoin d'avoir une expression régulière intégrée.

Eh bien, je ne voulais pas nécessairement dire que nous devrions réimplémenter le [[ intégré

Bien que, d'après ce que vous avez dit, peut-être que l'implémentation de notre propre test serait une meilleure construction, bien que, renommée en quelque chose comme cond , comme la façon dont fish implémente une math place de expr . Nous pourrions même aller jusqu'à implémenter des choses comme < et >, cependant, en utilisant le tri naturel (numérique) au lieu du tri lexicographique, afin que cela fonctionne sur les nombres aussi bien que sur les chaînes.

@Undeterminant builtin [[ vs builtin [ vs /bin/[ les différences subtiles sont déjà déroutantes dans bash ; s'il vous plaît, n'aggravons pas les choses en ajoutant des différences subtiles entre bash-[[ vs fish-[[ !
En outre, l'esprit de bash [[ viole la loi de l'orthogonalité - il "fixe" et/ou mais uniquement pour des conditions spécifiques que la construction prend en charge.

Il est ironique que les if commands...; then ...; fi bash admettent facilement des poissons et/ou entre if...then . Mais nous ne voulons pas d'un "alors". Peut-être que la chose à corriger est de faciliter le début... la fin.

Voici une idée bizarre (je ne suis pas du tout sûre que ça me plaise) :

if (foo; and bar)
  ...
end

Actuellement, (...) au démarrage de la commande est illégal ; la lecture naturelle est d'exécuter ceci et d'utiliser la sortie comme nom de commande mais nous avons besoin de eval pour cela.
Si nous sommes convaincus que nous n'autoriserons jamais cette lecture directement, nous pourrions réutiliser (...) nu pour signifier begin ...; end .
Ne pas capturer le stdout dans cette position est incohérent - mais très compact et propre.

Ce que je déteste à ce sujet, c'est que if (...) demande encore un autre sens : capturez la sortie et attribuez-lui une interprétation booléenne. Par exemple, if (math 2 \< 4) — math ne renvoie pas d'état, il affiche 0 ou 1 sur stdout. Une utilisation importante serait if $saved_bool .
Je ne pense pas que ce soit pratique - il n'y a pas une seule affectation correcte des significations booléennes aux chaînes, d'autant plus que 0/1 est désespérément confus. Mais lorsque vous rencontrez pour la première fois if (...) , cela semble une supposition raisonnable.

Pour des raisons de compatibilité, veuillez fournir les opérateurs communs que l'on trouve dans bash et zsh. Plus il devient facile pour les nouveaux utilisateurs de copier et coller la plupart des fonctionnalités de leur coquille précédente, meilleur sera le taux d'absorption des poissons. Je trouve que même si j'aime mieux le poisson à bien des égards, certains de ces petits obstacles idiots en font simplement plus un problème qu'un avantage lorsque j'arrive avec plus de 15 ans de personnalisation de coque qui ne devrait vraiment pas être un problème à prendre en charge .

Honnêtement, je ne vois pas && comme un « petit obstacle idiot ». Ce ne serait pas difficile à apprendre si vous considériez le poisson comme son propre langage au lieu d'un "coquille de remplacement" comme zsh. Si vous lisez le tutoriel sur le fonctionnement du poisson du début à la fin, je ne pense pas que ce soit difficile à comprendre.

Avoir quelque chose comme command1; and command2 montre plus clairement que le and est une exécution conditionnelle de command2 et pas seulement une jointure entre command1 et command2 .

Mais @Undeterminant , vous ne le voyez pas comme la plupart des gens le voient au début lorsqu'ils le découvrent initialement, etc. Laissez ce sentiment ou ce niveau de compétence venir avec le temps. Par exemple, j'ai importé des centaines de lignes de l'ancienne configuration héritée et honnêtement, je n'ai pas le temps de convertir immédiatement tout ce qui doit être converti. Je trouve des bizarreries dans lesquelles aucun numéro de ligne ne revient du poisson concernant l'endroit où se situe mon problème dans mes anciennes configurations.

Je peux comprendre votre point de vue, mais il est biaisé en ce qui concerne quelqu'un qui veut faire le changement et aimerait le faire au fil du temps plutôt que de passer par-dessus une grosse bosse. S'il vous plaît, ne vous méprenez pas, si je ne me souciais pas du poisson et que j'essayais donc de donner mon avis, je retournerais certainement à zsh tout de suite. Je pense que ce genre de réflexion et de raisonnement est important pour ouvrir un peu plus la porte aux nouveaux arrivants.

Alors oui, vous avez raison sur la lisibilité, mais laissons l'ancien fonctionner et donnons un avertissement plutôt qu'une erreur pour sevrer les gens.

@ylluminate Vous vous trompez. Même si fish prenait en charge && vous ne pourriez toujours pas utiliser votre configuration à partir de bash ou de zsh, car il y a plus de différences dans la syntaxe de script que les seuls opérateurs logiques.

Exactement. fish est fonctionnellement différent, ce qui signifie que vous ne devez pas simplement copier-coller le code directement. Si votre code est écrit en bash, à moins qu'il n'y ait un besoin explicite de le convertir en fish, gardez-le simplement en bash ; ce sont des langues distinctes.

Alors
si je fais
commande1 && commande2
dans le poisson, cela suggère qu'à la place je tape
commande1 ; et commande2

Est-ce que quelqu'un croit vraiment que (dans la ligne de commande) la deuxième option est plus propre, plus futuriste et plus facile à taper ?

Il est plus propre, car il s'appuie sur la syntaxe existante pour l'exécution des commandes, au lieu d'introduire une nouvelle syntaxe.

Considérez dans bash :

foo & bar # executes foo in the background, then bar in the foreground
foo && bar # executes foo in the foreground, then executes bar if foo has a zero exit status
foo & bar && baz & qux # left as an exercise for the reader

C'est le genre de non-sens que nous espérons éviter en utilisant des commandes au lieu d'une syntaxe spéciale.

Cette décision de conception a certainement un coût, en particulier dans les instructions if, que nous devrions essayer de réduire. Mais nous devrions l'aborder du point de vue « trouvons des moyens d'améliorer le poisson dans le cadre de sa philosophie de conception » plutôt que « trouvons des moyens de rendre le poisson plus semblable aux autres coquillages ».

Votre code fait ce qui suit, n'est-ce pas (en supposant que vous puissiez utiliser & avec des blocs) ?

foo &
if bar
    baz
end &
qux

Pour moi, cela semble artificiel. De plus, si la syntaxe de & est si confuse, pourquoi ne pas intégrer background , ou quelque chose du genre ?

Je pense que c'est en effet un argument pour faire de l'arrière-plan un élément intégré, bien que je ne propose pas que nous le fassions réellement.

Le problème avec ; and et ; or est qu'ils interagissent mal avec les tuyaux. condition; and echo stuff | grep stuff ne fonctionne pas, alors que condition && echo stuff | grep stuff fait. Je ne vois aucun moyen de contourner ce problème, sauf pour ajouter une syntaxe spéciale.

and echo stuff | grep stuff semble fonctionner pour moi. Pouvez-vous expliquer comment il est cassé?

@ridiculousfish voici le cas que j'ai découvert en essayant du poisson. L'expression or est vraie en dehors de l'instruction if mais (semble être ?) fausse lorsqu'elle est utilisée dans une instruction if. A moins que je manque quelque chose ici?

root@smogon-dev ~# test 0 = 1; or echo stuff | grep stuff
stuff
root@smogon-dev ~# echo $status
0
root@smogon-dev ~# if test 0 = 1; or echo stuff | grep stuff
                       echo Success
                   else
                       echo Failure
                   end
Failure

Comparez avec bash :

~/smogon/bin$ [[ 0 == 1 ]] || echo stuff | grep stuff
stuff
~/smogon/bin$ echo $?
0
~/smogon/bin$ if [[ 0 == 1 ]] || echo stuff | grep stuff; then
> echo Success
> else
> echo Failure
> fi
stuff
Success

Dans ce cas:

if test 0 = 1; or echo stuff | grep stuff

ça serait peut-être plus clair si c'était écrit comme ça :

if test 0 = 1
    or echo stuff | grep stuff
    ...

L'instruction or est dans le corps if ! Les booléens étant des commandes, ils n'ont pas de priorité particulière.

Vous pouvez utiliser begin/end comme "parenthèse":

if begin; test 0 = 1; or echo stuff | grep stuff ; end
    ...

Je pense donc que ce n'est pas lié aux tuyaux, mais plutôt à la priorité.

Comme vous pouvez le voir dans ce bogue, il y a beaucoup d'opinions quant à savoir si les poissons doivent prendre en charge les opérateurs booléens :)

alors, merci les gars pour l'énergie mise ici.

Mon intention n'est pas d'amener la discussion sur ce qui est mieux ou pas. C'est juste une chose pratique.
Comme la plupart d'entre vous, j'ai mes propres scripts à exécuter. Même dans des choses très simples, la condition && garantit le succès de la commande (sortie 0), tandis que ";" allez-y sans vous soucier de ce qui s'est passé. À droite? Donc, ce ne sont pas du tout les mêmes. J'espère que nous sommes tous d'accord là-dessus. :)

Donc, j'ai mes scripts et aucun d'entre eux ne fonctionne avec du poisson. Oui, j'utilise beaucoup &&. Mais cela se produit également avec n'importe quelle paix de code sur le net avec bash, généralement en utilisant && aussi. Pour faire court, le truc c'est que je ne peux plus utiliser mes codes ! :RÉ

Je me demandais... Est-il possible d'établir une fonction ou une définition dans le fichier de configuration du poisson afin de corriger ce comportement UNIQUEMENT (ce qui signifie juste &&) et de le rétablir tel qu'il est dans le bash traditionnel ? C'est possible? Plausible? Faisable?

Encore une fois, je suis d'accord que l'utilisation de "et" peut être plus agréable, plus claire. Mais cela ne fonctionne pas avec mon code ou, en général, avec tout code bash ci-dessus pour débutant. Donc, au lieu de changer le code déjà écrit en remplaçant && (... n'arrivera pas... et ne fonctionnera probablement pas), il serait plus facile de permettre aux poissons de comprendre le bash traditionnel si quelqu'un veut ou a besoin, non?

Tous les meilleurs gars, et merci encore pour l'effort !!

Avons-nous déjà été plus proches de la compatibilité avec les scripts bash / zsh ? J'ai abandonné fish selon mes commentaires précédents parce que je ne vais pas prendre le temps de convertir toute l'infrastructure que j'ai déjà construite dans mes environnements shell sur autant de postes de travail et de serveurs. J'adorerais faire un autre essai si nous sommes plus proches. Sinon, je continuerai à colporter sans ça. Merci.

@rhoconlinux Changer Fish pour prendre en charge && ne fera pas fonctionner vos scripts bash. Il y a bien plus de différences que ça.

je n'ai pas compris ta réponse ^_^
Est-il possible de définir un alias ou une fonction pour le problème && ?

@rhoconlinux Non, il faudrait modifier l'analyseur Fish (en C++). Ce que je veux dire, c'est que si Fish supportait && , vos scripts Bash échoueraient toujours à s'exécuter, à cause de toutes les autres différences entre Fish et Bash.

@kballard aïe ! hmmm.... Je suis si triste d'entendre ça. Je l'ai maintenant. Hyper clair. :)

Merci pour le retour ultra-rapide. J'utiliserai du poisson pour une expérience quotidienne plus agréable et je garderai alors un terminal bash pour mes affaires.

Acclamations! :+1:

Si && est un problème, c'est facile d'y faire face.

sed 's/&&/; and /' ~/.bashrc > ~/.config/fish/config.fish

Mais il est peu probable que ce soit la seule chose que vous aurez à faire. Ce que vous voulez dire, c'est une implémentation de #522.

Je dirais que la principale motivation de la compatibilité && n'est pas de convertir l'existant
bases de code mais copier-coller à partir d'Internet.
Par exemple, je vois un extrait de sudo add-apt-repo... && sudo apt-get update && sudo apt-get install ... , je veux juste copier-coller mais cela échoue.

Ce n'est pas quelque chose que nous pouvons résoudre par l'éducation — il y aura toujours
des extraits à coller, et ils utiliseront la syntaxe [ba]sh standard.
Et && est de loin le problème n°1 auquel je me heurte.
( export FOO=bar est #2 mais peut être résolu par function export; set -x -g (echo $argv | sed 's/=/\n/'); end .)

Ce n'est pas un problème profond cependant : j'ai pris l'habitude de taper
bash , coller, Ctrl+D.
Hmm, je suis tenté d'ajouter un raccourci clavier pour exécuter actuel/précédent
ligne de commande sous bash.

Mes deux cents sur la question:
Je travaille sur un outil de déploiement (https://github.com/andres-montanez/Magallanes) qui effectue des appels de commandes shell, et la majorité des utilisateurs et contributeurs utiliseront un shell bash. Alors bien sûr, ici et là '&&' sont utilisés pour enchaîner les commandes.

Il existe des solutions de contournement évidentes (comme passer toutes les commandes explicitement à bash)
Mais cela apporte un certain nombre de points douloureux. D'une part, il peut y avoir des effets secondaires étranges (c'est-à-dire que le PATH et les autres variables ne sont pas définis de la même manière), cela signifie pirater certaines parties essentielles de l'outil dans ce seul but, et je dois fusionner mes correctifs d'une version à l'autre chaque fois que je mets à jour.

&& n'est qu'une des nombreuses fonctionnalités de bash avec lesquelles fish n'est pas compatible, mais c'est peut-être la plus basique et la plus utilisée. Par exemple, l'outil ci-dessus est en PHP, donc tout ce qui est complexe est fait en PHP et seules les commandes système de base sont transmises au shell. Frapper des incompatibilités de syntaxe avec un cas d'utilisation aussi minimal est frustrant.

Je suis tout à fait d'accord avec ce que @cben a dit que && est à mon avis un cas particulier car il existe des centaines d'extraits de code en ligne où la seule différence entre copier et coller ou non est la prise en charge de && .
Bien que je sois d'accord, il est important de prendre en considération la façon dont fish avance en termes de syntaxe, etc. Je pense que c'est quelque chose qui faciliterait la vie de tant de développeurs qui utilisent ou veulent utiliser fish. Je sais que cela ressemble à un simple remplacement de && par ; and mais c'est toujours ennuyeux et ça me rend un peu gênant quand je dis aux autres à quel point le poisson est incroyable mais ensuite je dois bidouiller et changer certains mots-clés, ils se demandent généralement pourquoi je dois changer une chose aussi simple. Ensuite, je dois défendre le poisson et ce n'est pas un bon argument pour promouvoir le poisson.
Parfois, ce sont vraiment les choses les plus simples qui peuvent avoir le plus d'impact.
Donc, en bref, je suis tout à fait pour autoriser la syntaxe bash && .

Je suis d'accord avec ce que @Globegitter et @cben ont dit. Une grande quantité de scripts et de programmes dépend de && et || . J'utilise fish shell sur mon poste de travail et ce serait bien d'avoir une compatibilité cross-shell lors de l'écriture de scripts.

Étant donné qu'il existe de nombreuses différences significatives entre les scripts Fish et les scripts Bash au-delà de seulement && et || , pourquoi tous ceux qui commentent ici pensent-ils que faire accepter à Fish && serait avoir un sens ? Si vous devez exécuter un extrait de code Bash, exécutez simplement bash , exécutez l'extrait, puis revenez à Fish.

Je pense que beaucoup de gens aimeraient "se convertir" au poisson, mais ont une infrastructure à apporter. J'ai, par exemple, 15 ans de scripts shell sur mon seul poste de travail (sans parler d'autres serveurs sur lesquels j'aimerais également exécuter du poisson) que je ne veux pas avoir à passer du temps à convertir. Cela ne me dérange pas de fouiller et de faire fonctionner les choses "à la manière du poisson" au cours de plusieurs mois, mais il n'y a aucun moyen que je puisse faire ce genre d'investissement initial dans mon flux de travail pour passer à une autre coquille.

Je pense que le poisson aurait un afflux important d'utilisateurs si le problème de compatibilité général était résolu, mais il ne semble pas que ce soit une priorité pour le projet d'après ce que disent d'autres qui travaillent dans le développement du poisson. Je garde les yeux sur cela pour cette raison même car j'aimerais éventuellement passer à la pêche si le paysage change à cet égard.

En ce qui concerne simplement l'exécution de bash ou zsh selon les besoins, cela représenterait une quantité importante d'exécution de ces shells dans mon cas et il est tout simplement idiot de suivre cette voie autrement.

@kballard J'ai un flux de travail idéal pour 95% des scripts que je fais avec fish : cmd+C un script très simple d'une autre source, cmd+tab vers iTerm, cmd+v et Enter. C'est tout ce que je veux faire, pas de bash supplémentaire ou quoi que ce soit d'autre, rien d'autre. La plupart du temps, la seule chose qui empêche ces scripts de fonctionner avec ce workflow précis est qu'il y a un && présent. C'est donc la raison pour laquelle pour moi et je suppose que la plupart des autres ici, résoudre ce problème serait très utile.
Si vous ne faites pas l'expérience de cela vous-même, croyez-moi, cela s'additionne et vous reste vraiment à l'esprit si votre flux de travail est interrompu si souvent.

J'aime le poisson pour tout le reste et c'est pourquoi je ne pouvais pas revenir en arrière, mais cette chose simple est juste ce qui l'empêche d'être génial pour moi et je suppose que certains des autres ici.

Voici. Une fois le PR #1633 atterri, vous pouvez prendre les éléments suivants et les enregistrer dans ~/.config/fish/functions/fish_user_key_bindings.fish :

function handle_input_bash_conditional --description 'Function used for binding to replace && and ||'
    # This function is expected to be called with a single argument of either & or |
    # The argument indicates which key was pressed to invoke this function
    if begin; commandline --search-mode; or commandline --paging-mode; end
        # search or paging mode; use normal behavior
        commandline -i $argv[1]
        return
    end
    # is our cursor positioned after a '&'/'|'?
    switch (commandline -c)[-1]
    case \*$argv[1]
        # experimentally, `commandline -t` only prints string-type tokens,
        # so it prints nothing for the background operator. We need -c as well
        # so if the cursor is after & in `&wat` it doesn't print "wat".
        if test -z (commandline -c -t)[-1]
            # Ideally we'd just emit a backspace and then insert the text
            # but injected readline functions run after any commandline modifications.
            # So instead we have to build the new commandline
            #
            # NB: We could really use some string manipulation operators and some basic math support.
            # The `math` function is actually a wrawpper around `bc` which is kind of terrible.
            # Instead we're going to use `expr`, which is a bit lighter-weight.

            # get the cursor position
            set -l count (commandline -C)
            # calculate count-1 and count+1 to give to `cut`
            set -l prefix (expr $count - 1)
            set -l suffix (expr $count + 1)
            # cut doesn't like 1-0 so we need to special-case that
            set -l cutlist 1-$prefix,$suffix-
            if test "$prefix" = 0
                set cutlist $suffix-
            end
            commandline (commandline | cut -c $cutlist)
            commandline -C $prefix
            if test $argv[1] = '&'
                commandline -i '; and '
            else
                commandline -i '; or '
            end
            return
        end
    end
    # no special behavior, insert the character
    commandline -i $argv[1]
end

function fish_user_key_bindings
    bind \& 'handle_input_bash_conditional \&'
    bind \| 'handle_input_bash_conditional \|'
end

Cela lie & et | et le fait de taper && ou || le traduit automatiquement en ; and / ; or approprié command one && command two et de le faire fonctionner.

Notez que jusqu'à ce que PR #1633 soit accepté, ce script fonctionnera pour _typing_ && / || mais ne fonctionnera pas pour le coller.

@kballard Wow, c'est une excellente nouvelle ! Merci beaucoup.

On dirait que cela ne gère pas correctement le mode de recherche (je ne suis pas sûr du mode pager ; je ne sais pas exactement ce que cela comprend). Appuyer sur & ou | pendant la recherche met fin à la recherche. Cela dit, je ne sais pas comment gérer ça.

J'ai mis à jour le script avec une correction de bogue pour taper | ou & dans une commande multiligne.

@kballard j'ai vu que le PR a atterri. Donc, le script que vous avez collé ci-dessus devrait faire fonctionner && avec le dernier master ?

Ouais ça devrait. Essayez-le et faites-moi savoir si vous avez des problèmes.

-Kévin

Le 1er septembre 2014, à 01h14, Markus Padourek [email protected] a écrit :

@kballard j'ai vu que le PR a atterri. Donc, le script que vous avez collé ci-dessus devrait faire fonctionner && avec le dernier maître ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

J'ai essayé ce script avec la nouvelle version 2.1.1 publiée il y a quelques jours, et cela ne semble pas fonctionner. Dois-je attendre le 2.2 ? Merci!

@pragmattica : 2.1.1 était une version de correction de

@xfix : D'accord. Merci de me le faire savoir. J'ai hâte d'être au 2.2 !

IMPRESSIONNANT :+1 :

Un journal des modifications en cours d'exécution est-il disponible ? Il semble que la racine CHANGELOG soit assez obsolète.

@pragmattica Maintenant que fish 2.2 est sorti, j'ai essayé cela sur Ubuntu 14.04 et echo 'test1' && echo 'test2'; se transforme en echo test1 &; and echo 'test2';

Pourrait-il y avoir un problème quelque part dans le fish_user_key_bindings.fish ? (Je vais essayer d'y jeter un coup d'œil moi-même, mais mes connaissances en script fish/bash sont un peu fragiles)

Edit: Cela semble fonctionner cependant lorsque vous tapez une commande avec && . Ce serait peut-être un peu sympa si cela se produisait sur l'espace par la suite, mais ce n'est pas vraiment important. Super que la moitié fonctionne :)

-1 aux symboles étranges :

if [[ a = b ]]; and [[ b = a ]]; or [[ c = b ]]; then echo hello; and echo world; done

+1 aux symboles simples :

if [[ a = b ]] && [[ b = a ]] || [[ c = b ]]; then echo hello && echo world; done

Aaahhh Je pense savoir quel est le problème @pragmattica la commande commandline renvoie le tampon sans guillemets. Oui ça a l'air d'être ça. Ainsi, une fois que https://github.com/fish-shell/fish-shell/issues/2210 est corrigé, le script ci-dessus devrait également être corrigé.

Est-ce encore un début envisagé ?

+1
Les symboles ne sont pas étranges, ils sont couramment utilisés pour la logique dans un grand nombre de langages de programmation.
La compatibilité copier-coller est un argument très réel, que je soutiens.

Je vais être le méchant et clore cette discussion. Cela ne sera pas mis en œuvre. Je suis particulièrement gêné par les déclarations répétées sur le fait de vouloir pouvoir "couper et coller des commandes à partir de scripts bash". Même si fish prenait en charge les opérateurs && et || , cela ne garantirait pas que vous puissiez simplement couper et coller des instructions contenant ces opérateurs. Nous ne voulons pas donner l'impression que vous pouvez le faire. Honnêtement, si vous voulez la syntaxe et le comportement bash/zsh, vous devez utiliser ces shells (ou une alternative qui prétend être compatible avec eux).

La plupart des autres idées discutées devraient avoir leurs propres problèmes. En particulier, il peut être intéressant d'implémenter certains des comportements [[ ... ]] qui ont été introduits pour la première fois par ksh88 (pas bash). Mais probablement en améliorant la commande intégrée test ou une nouvelle commande plutôt qu'en implémentant ces jetons spéciaux.

Je suis toujours très perturbé par cette notion de ne pas supporter zsh et bash. Je peux comprendre la logique, mais je ne suis pas d'accord avec elle. J'étais très intéressé par le poisson il y a quelque temps, mais j'ai reculé à cause de cette opposition. Il y aura peut-être une opportunité de bifurquer le projet ici si nous sommes assez nombreux, en tant que développeurs, à souhaiter que cela soit mis en œuvre. Triste de voir cette résistance continue qui entrave finalement l'élan vers l'avant et l'acceptation d'un travail aussi intéressant.

@ylluminate qu'avez-vous en tête en "supportant zsh et bash ?" Quel niveau de compatibilité voudriez-vous voir?

Je suis toujours très perturbé par cette notion de ne pas supporter zsh et bash. Je peux comprendre la logique...

Je crains de ne pas comprendre votre logique pour avoir des fonctionnalités bash et zsh de support de poisson. Si vous voulez Java pourquoi utiliser C++ ? Si vous voulez Perl, pourquoi utiliser Python ? Comme @ridiculousfish vient de le demander, à part du sucre syntaxique, qu'est-ce que le poisson aurait à supporter pour vous rendre heureux ? À quel moment le poisson devient-il un autre clone de bash ?

PS, je programme pour gagner ma vie depuis 1979 et j'utilise UNIX depuis le milieu des années 80. J'ai utilisé tellement de shells que j'en ai perdu le compte (par exemple, Bourne, Csh, Ksh88, Ksh93, Bash, Zsh, Xonsh). Changer de shell demande toujours du travail (c'est pourquoi je ne le fais pas plus d'une fois tous les cinq ans environ). Quand je le fais, je ne me plains pas que mon nouveau shell n'exécute pas tous mes scripts hérités sans changement.

@krader1961 Joli discours. A mon humble avis ...

Je ne ferais pas de scripts dans fish tout le temps car (suivi d'ordres):

1. le script de fish est lent (plus lent que mksh)
2. une syntaxe étrange (par exemple ; and , ; or qui m'a l'air moche)
3. pas compatible posix (je peux dire que la syntaxe est facile mais nécessite encore du temps pour apprendre)

Eh bien, je ne me soucierais pas des 2 et 3 uniquement si le script fish est plus rapide que les autres shells (par exemple, mksh, bash).

Par contre , j'utilise du poisson car :

1. le temps de démarrage est plus rapide que zsh (mais plus lent que bash)
2. avoir beaucoup de fonctionnalités activées par défaut (la surbrillance de la syntaxe est la meilleure)
3. les configurations sont agréables et simples (surtout set -Ux )

@ylluminate En regardant ce problème vieux de quatre ans, je peux voir à quel point les gens qui veulent profiter du poisson comme le bash sont paresseux/occupés. Les plus enthousiastes ont créé leur propre coquille (comme magicant/yash, elfique/elfique, michaelmacinnis/oh, et moi :-P). Si vous voulez faire les choses d'une manière non-poisson, vous avez probablement besoin d'une coquille non-poisson.

Si vous réfléchissez vraiment à la façon d'implémenter && || sur les poissons et que cela ne soit pas très compliqué, vous verrez peut-être que vous ne faites qu'expulser begin; end (voir ce que fait le commit 594b460ba2d8dca59a3bfd282397c5f33aa9da6f,compteur- ; and or jouer des doubles rôles,très un peu moche) et n'obtenez que peu de sucre.

@pickfire Pouvez-vous préciser "le script du poisson est lent ?" Y a-t-il des tests qui vous amènent à cette conclusion?

FWIW dans mes tests, fish est globalement plus rapide que bash, grâce à posix_spawn et à son analyseur rapide, bien qu'il puisse être plus lent dans certains cas comme alias .

ivan<strong i="5">@alarmpi</strong> /tmp> echo 'echo test' > script
ivan<strong i="6">@alarmpi</strong> /tmp> time bash script
test
0.02user 0.01system 0:00.03elapsed 96%CPU (0avgtext+0avgdata 2776maxresident)k
0inputs+0outputs (0major+149minor)pagefaults 0swaps
ivan<strong i="7">@alarmpi</strong> /tmp> time mksh script
test
0.00user 0.00system 0:00.02elapsed 0%CPU (0avgtext+0avgdata 1420maxresident)k
480inputs+0outputs (2major+82minor)pagefaults 0swaps
ivan<strong i="8">@alarmpi</strong> /tmp> time fish script
test
0.07user 0.01system 0:00.09elapsed 85%CPU (0avgtext+0avgdata 4204maxresident)k
352inputs+0outputs (2major+231minor)pagefaults 0swaps

@ridiculousfish Imaginez qu'il est déjà très lent par rapport aux autres pour un seul echo .

@krader1961 @ridiculousfish IMO, une fois que https://github.com/fish-shell/fish-shell/issues/2210 est publié, cela peut être fermé. Il existe une solution très simple que @kballard a publiée.

@pickfire Merci pour ce partage. Ce test mesure la surcharge de démarrage, pas le temps de echo . Le temps de démarrage est très important, mais vous ne pouvez pas tirer de conclusions au-delà du temps de démarrage (qui dépend principalement de config.fish) à partir de ce test.

Voici une autre micro-référence :

> cat test.fish
for i in (seq 1000)
    ls > /dev/null
end

> time fish test.fish
        1.51 real         0.74 user         0.65 sys

> cat test.sh
for i in {1..1000} ; do
    ls > /dev/null
done

> time bash test.sh
        2.01 real         0.85 user         1.12 sys

ici, le poisson gagne beaucoup, mais il s'agit principalement de mesurer la différence entre fork et posix_spawn.

Je pense qu'une conclusion ici est que nous avons besoin d'une suite complète de références.

@ridiculousfish Voilà, le benchmark que tu m'as donné :

> cat test.fish
for i in (seq 1000)
    ls > /dev/null
end
> time fish test.fish
4.18user 4.04system 0:22.62elapsed 36%CPU (0avgtext+0avgdata 4360maxresident)k
96inputs+0outputs (1major+321041minor)pagefaults 0swaps
> cat test.sh
for i in {1..1000} ; do
    ls > /dev/null
done
> time bash test.sh
0.70user 1.62system 0:09.81elapsed 23%CPU (0avgtext+0avgdata 2844maxresident)k
0inputs+0outputs (0major+154100minor)pagefaults 0swaps
> time mksh test.sh
0.00user 0.01system 0:00.04elapsed 24%CPU (0avgtext+0avgdata 1780maxresident)k
752inputs+0outputs (3major+203minor)pagefaults 0swaps

Le mksh semble avoir une vitesse impressionnante.

Le ls @pickfire fish est une fonction sous Linux qui fait d'autres choses pour rendre la sortie plus agréable, ce que bash ne fait pas. Si vous voulez une comparaison de pommes à pommes sur Linux, utilisez command ls . (Sur Darwin, l'emballage du poisson ls est beaucoup plus fin - j'aurais dû le souligner mais j'ai oublié.)

L'explication de la "vitesse impressionnante" de mksh dans votre test est que mksh n'a pas d'extension d'accolade, il n'appelle donc ls qu'une seule fois. Évidemment, invoquer ls une fois est beaucoup plus rapide que de l'invoquer 1000 fois.

Cela montre que la mesure des performances est très délicate - il est très facile de mesurer quelque chose de différent de ce que vous pensez mesurer !

@ridiculousfish , y a-t-il une raison d'utiliser la fonction ls script fish est comparé à command ls ? La sortie n'est pas importante pendant le script.

Bon, cette fois j'ai fait ce que tu as dit :

> cat test.fish
for i in (seq 1000)
    command ls > /dev/null
end
> time fish test.fish
0.66user 1.04system 0:08.08elapsed 21%CPU (0avgtext+0avgdata 4364maxresident)k
624inputs+0outputs (4major+113176minor)pagefaults 0swaps
> cat test.sh
for i in $(seq 1000) ; do
    ls > /dev/null
done
> time mksh test.sh
0.21user 0.65system 0:07.64elapsed 11%CPU (0avgtext+0avgdata 1884maxresident)k
0inputs+0outputs (0major+119632minor)pagefaults 0swaps
> time bash test.sh
0.15user 1.04system 0:08.66elapsed 13%CPU (0avgtext+0avgdata 2816maxresident)k
0inputs+0outputs (0major+150700minor)pagefaults 0swaps

Au final, mksh est toujours le plus rapide, maintenant je trouve impressionnant que fish soit plus rapide que mksh . Si fish avait une prise en charge intégrée de l'exécution de commandes parallèles, je pense que cela aurait été le plus rapide de tous.

Ce temps d'utilisation de 0,66 est assez élevé. Je suppose que cela est dû au contenu de votre config.fish - définissant des alias et autres. Pour info, voici ce que je vois sur ma box Linux (le meilleur sur 3 pour chacun) :

> time fish test.fish
0.15user 1.21system 0:01.33elapsed...
> time mksh test.mksh
0.12user 1.13system 0:01.24elapsed...
> time bash test.sh
0.18user 1.34system 0:01.47elapsed...

tout le monde est très proche.

Il pourrait être intéressant pour n'importe quel benchmark d'incorporer une sorte de "shell oraculaire" qui fait juste un fork/exec ou posix_spawn à une commande de chemin, afin que nous puissions avoir une idée de la distance à laquelle nous sommes de la vitesse maximale que le système d'exploitation peut fournir .

@ridiculousfish , mon config.fish est très court :

# Solarized colors
test $SHLVL = 2
and sh $HOME/.config/base16-shell/base16-solarized.dark.sh &
set fisher_home ~/.local/share/fisherman
set fisher_config ~/.config/fisherman
source $fisher_home/config.fish

Eh bien, parce qu'il utilise probablement fisherman , je ne sais pas si cela le ralentira. @bucaran est le gars sympa pour ça. Cette fois, j'ai vidé le config.fish (meilleur résultat sur 5 tentatives) :

> time fish test.fish; time mksh test.sh; time bash test.sh
0.62user 1.09system 0:07.28elapsed 23%CPU (0avgtext+0avgdata 4396maxresident)k
0inputs+0outputs (0major+108240minor)pagefaults 0swaps
0.21user 0.62system 0:06.92elapsed 11%CPU (0avgtext+0avgdata 1888maxresident)k
0inputs+0outputs (0major+116674minor)pagefaults 0swaps
0.29user 0.81system 0:07.78elapsed 14%CPU (0avgtext+0avgdata 2780maxresident)k
0inputs+0outputs (0major+145628minor)pagefaults 0swaps

@ridiculousfish @pickfire Pouvez-vous discuter dans un autre numéro pour que je puisse bloquer vos messages ?

Oui, désolé d'avoir spammé ce problème. @pickfire si vous souhaitez suivre certains points de repère que vous jugez particulièrement intéressants ou pertinents, n'hésitez pas à ouvrir un autre numéro.

À propos de la compatibilité bash et zsh, personnellement, je ne m'attends pas à une compatibilité complète, mais avec chaque degré de compatibilité, le poisson ajouté peut devenir plus populaire.
Même sans tenir compte des scripts, && et || sont importants car ils sont très couramment utilisés pour enchaîner des commandes. Par exemple, j'ai toujours des problèmes avec le #2292. Je sais que cela peut être considéré comme n'étant pas un insecte de poisson, mais le fait est que l'amélioration de la compatibilité avec les poissons le résoudrait.

Je suis avec maxfl ici, :-1: pour avoir || et && dans le cadre de la syntaxe du poisson, si cela est censé être un vote populaire.

Le poisson n'est pas bash (ou zsh). Il n'y a aucune raison impérieuse d'implémenter && et || autre que la compatibilité avec ces shells. La compatibilité avec le statu quo est un anti-objectif de ce projet.

@Nodd : Votre référence au problème n°2292 est en fait un exemple des raisons pour lesquelles les poissons ne devraient pas implémenter cette syntaxe. Ce serait une autre étape pour faire croire aux gens que le poisson est un clone POSIX (bash, zsh, etc.). Cela créerait simplement d'autres exigences pour que les poissons se comportent comme ces coquillages dans d'autres régions.

Pour toutes les personnes qui recherchent une solution, depuis fish 2.3, je peux confirmer qu'il existe enfin une solution entièrement fonctionnelle.

Faites simplement ce que la réponse ci-dessus mentionne :

Voici. Une fois le PR #1633 atterri, vous pouvez prendre ce qui suit et l'enregistrer dans ~/.config/fish/functions/fish_user_key_bindings.fish :

function handle_input_bash_conditional --description 'Function used for binding to replace && and ||'
    # This function is expected to be called with a single argument of either & or |
    # The argument indicates which key was pressed to invoke this function
    if begin; commandline --search-mode; or commandline --paging-mode; end
        # search or paging mode; use normal behavior
        commandline -i $argv[1]
        return
    end
    # is our cursor positioned after a '&'/'|'?
    switch (commandline -c)[-1]
    case \*$argv[1]
        # experimentally, `commandline -t` only prints string-type tokens,
        # so it prints nothing for the background operator. We need -c as well
        # so if the cursor is after & in `&wat` it doesn't print "wat".
        if test -z (commandline -c -t)[-1]
            # Ideally we'd just emit a backspace and then insert the text
            # but injected readline functions run after any commandline modifications.
            # So instead we have to build the new commandline
            #
            # NB: We could really use some string manipulation operators and some basic math support.
            # The `math` function is actually a wrawpper around `bc` which is kind of terrible.
            # Instead we're going to use `expr`, which is a bit lighter-weight.

            # get the cursor position
            set -l count (commandline -C)
            # calculate count-1 and count+1 to give to `cut`
            set -l prefix (expr $count - 1)
            set -l suffix (expr $count + 1)
            # cut doesn't like 1-0 so we need to special-case that
            set -l cutlist 1-$prefix,$suffix-
            if test "$prefix" = 0
                set cutlist $suffix-
            end
            commandline (commandline | cut -c $cutlist)
            commandline -C $prefix
            if test $argv[1] = '&'
                commandline -i '; and '
            else
                commandline -i '; or '
            end
            return
        end
    end
    # no special behavior, insert the character
    commandline -i $argv[1]
end

function fish_user_key_bindings
    bind \& 'handle_input_bash_conditional \&'
    bind \| 'handle_input_bash_conditional \|'
end

@Globegitter

Et juste ?

function sudo_bang_bang --on-event fish_postexec
    abbr !! sudo $argv[1]
end

@brj Mettre également cela dans ~/.config/fish/functions/fish_user_key_bindings.fish ? Cela n'a pas semblé faire l'affaire pour moi.

Vous devez sourcer cette fonction. Donc, vos options sont de le mettre dans votre config.fish ou de le mettre dans ~/.conf.d/[name-dont-matter].fish.

@brj : Mauvais problème pour cette fonction. Il s'agit de "&&" et "||", pas de "!!" - différentes choses.

@faho lol, tu as raison. Je reçois toujours une notification de ce problème, alors j'ai pensé que c'était un autre cas de sudo !!.

@Globegitter Désolé pour la confusion !

Que diriez-vous d'expédier la solution de contournement proposée avec du poisson comme exemple, afin que les utilisateurs puissent facilement la copier ? Le message d'erreur pourrait facilement être augmenté pour mentionner cela. Je continue de coller le même liner (de gerrit code-review) où && est utilisé car il fonctionne dans à peu près tous les shells (y compris windows cmd.exe en plus des shells unix-y). Pour moi, le script mentionné ci-dessus est un booster de productivité (j'ai tapé bash -c "coller ici" pendant un moment...).

Comment fais-je && ? Y a-t-il une résolution ?

Même problème que ci-dessus, je ne trouve vraiment aucun moyen de faire

gcc test2.c -o a.out && ./a.out

dans le poisson.

gcc test2.c -o a.out; and ./a.out

@ivan a essayé, mais il donne "et" et "./a.out" comme arguments à gcc.

//edit: Soit dit en passant, j'ai fini par utiliser le script bash, car cela semble être complètement impossible dans fish :(

gcc test2.c -lwlc -o a.out && (( sleep 2s; DISPLAY=:2 xterm ) & ./a.out)

Je fais cette chose "complètement impossible" assez souvent. Essayez peut-être la syntaxe ; and dans un environnement de poisson propre ? Si cela ne fonctionne pas, peut-être que quelque chose ne va pas avec vos points-virgules ? Tapez-vous ceci dans fish, ou est-ce que cela vient d'un autre programme ?

@ivan en le saisissant .

Désolé pour cette question probablement stupide, mais comment faire des parenthèses ? Je ne trouve pas un mot à leur sujet dans la documentation et ce n'est pas exactement un sujet google :(

gcc test2.c -lwlc -o a.out && (( sleep 2s; DISPLAY=:2 xterm ) & ./a.out)

@kozec Je pense que vous avez juste du mal à regrouper vos articles ici. Ce que vous devez utiliser est begin comme une accolade gauche (c'est comme ça que je le pense) et end comme une droite.

gcc test2.c -lwlc -o a.out; and begin sleep 2s; env DISPLAY=:2 xterm; end & ./a.out

ou en retrait :

      gcc test2.c -lwlc -o a.out
         and begin sleep 2s
             env DISPLAY=:2 xterm
         end & ./a.out

@floam Merci, ça marche presque. Mais les choses avant et ne sont pas envoyées en arrière-plan :(

Exemple minimal :

begin sleep 2s ; env DISPLAY=:2 xterm ; end & Xephyr :2

dort 2s, puis lance xterm, _then_ démarre XServer pour ce xterm. xterm ofc plante avant que XServer ne soit prêt.

Ah désolé. Le problème : https://github.com/fish-shell/fish-shell/issues/238

Vous constaterez que vous pouvez contourner cela par ceci où vous devez, pas joli:

fish -c 'sleep 2s; env DISPLAY=:2 xterm' & Xephyr :2

Lorsque vous avez une grande quantité de scripts existants, pour le développement, la construction et à l'intérieur des scripts d'exécution npm, il n'est pas raisonnable de changer, d'autant plus que certains/la plupart ne sont pas sur fish. Pour les scripts bash réguliers avec shebang et tout ce n'est pas un problème bien sûr.

Ce qui est bien (ou "bien") à propos de &&, c'est qu'il fonctionne sur les shells normaux non seulement sur Linux et Mac, mais aussi sur Windows, ce qui est bien pour une configuration rapide des environnements de développement, etc.

Ce n'est en aucun cas un facteur de rupture, mais il est difficile de voir pourquoi l'ajouter le serait non plus ?

Eh bien, c'est un argument plutôt idiot à avoir. Pourquoi ne pas avoir différents "modes" pour le compilateur fish ? C'est-à-dire, une sorte de paramètre que vous pouvez activer dans lequel vous pouvez avoir des trucs de poisson "purs" ou vous pouvez avoir une compatibilité avec des coquillages de type bash avec des fish-isms. Vous pouvez même avoir différents "niveaux" de compatibilité pour d'autres shells afin que vous puissiez avoir une compatibilité totale, aucune compatibilité ou quelque chose entre les deux. Je veux dire, à un niveau de base, vous pourriez au moins implémenter une sorte de compilateur source à source pour cela. Ou prenez le code bash et traduisez-le en une représentation interne intermédiaire pour le poisson. Vous pourriez faire toutes sortes de choses pour la traduction à cet égard. Corrigez-moi si je me trompe, mais je pense que les concepts de niveau linguistique de bash et al. contre les poissons ne sont pas si différents du monde, n'est-ce pas ?

Quoi qu'il en soit, c'est mon 0,02 $ sur ce problème qui semble vraiment idiot car il repose sur le principe :

"pure fish"
XOR
"compatibility with bash / becoming another bash clone"

quand il n'y a rien qui empêche d'avoir un ou plusieurs compromis entre ces deux notions.

On devrait au moins faire face à la réalité que les coquillages de type bash sont beaucoup plus standard et populaires que les coquillages plus ésotériques tels que le poisson, donc il devrait vraiment y avoir une sorte de couche de compatibilité pour toute chance réaliste que le poisson devienne un coquillage capable de se tenir debout. -toe toe with bash en termes d'être répandu et de ne pas causer de maux de tête de compatibilité.

...quand rien n'empêche d'avoir un ou des compromis entre ces deux notions.

Rien d'autre qu'une personne (ou un groupe de personnes) investissant plus de 2 000 heures (une année-personne) pour écrire le code nécessaire. J'ai hâte d'examiner les pull- requests de votre part,

Mis en œuvre en #4620.