Bruno Michel a écrit 3285 commentaires

Les exécutables en go font quelques Mo pour des outils en ligne de commande du type de ceux cités dans la dépêche. Par exemple, gops fait 3,9 Mo chez moi et peco, cité dans un autre commentaire de cette dépêche, fait 4,8 Mo. Pour comparer, Le binaire de ripgrep (Rust) fait 3,8 Mo, celui d'exa (Rust) 1,7 Mo.

Les 4 programmes cités ci-dessus s'exécutent en moins d'un centième de seconde, le plus rapide étant peco (Go).

Le cas d'usage est intéressant, mais ça reste un cas assez rare. J'ai l'impression que ça aurait plus sa place dans une extension pour Firefox.

-tout admin qui se respecte et a plus d'une poignée de machines à gérer utilise maintenant un système de gestion de configuration (ansible, puppet, salt, chef…) qui lui permet de déployer le profile de son utilisateur ainsi que des binaires sur l'ensemble du parc.

Les admins que je connais gèrent plusieurs parcs (un ou plusieurs pour le boulot, un pour leurs serveurs à eux, un ou plusieurs pour des associations, etc.), avec parfois différents outils de gestion de configuration et différentes distributions Linux ou BSD. Ça n'aide pas pour déployer partout les mêmes outils et configurations. Et même quand il y a un seul parc, ils n'aiment pas déployer dessus des choses qui ne sont pas strictement nécessaires.

Non, ça ne fait pas la même chose. Un git grep, ça ignore le répertoire .git mais aussi tous les fichiers et répertoires listés dans le .gitignore, et c'est quasiment toujours ce que je veux.

Quand je travaille sur un projet avec du JS, il y a toujours plein de trucs dans les node_modules et ça fait des correspondances qui ne m'intéressent pas quand je fais une recherche. Quand je travaille sur LinuxFr.org, c'est les avatars uploadés (des fichiers binaires) qui faisaient parfois des correspondances dont je ne veux pas sur des recherches. Quand je travaille sur cozy-stack, c'est le répertoire storage que je veux ignorer. Etc.

Il n'y aurait besoin que d'ignorer des répertoires connus à l'avance, un alias me suffirait bien. Mais ripgrep m'apporte plus que ça.

OK, je suppose que ça ne doit pas être ce glimpse là : http://getglimpse.com/. Tu aurais un lien ?

D'un point de vue fonctionnel, quitte à installer un nouveau paquet, pourquoi installer glimpse plutôt que ripgrep ? Qu'est-ce qu'il apporte de plus ?

Heu, cscope, je viens de faire un essai rapidement et ça a l'air nettement moins pratique :

1. Ça ne fait que du C et dérivés
2. Ça a l'air bizarre à utiliser, on ne lance pas la commande et des résultats s'affichent sur la sortie standard, mais on passe par une interface en ncurses (avec CTRL-D pour quitter, ce n'est pas super intuitif)
3. Il construit une base de références (comme ctags) et laisse traîner un fichier cscope.out
4. Sur une recherche, il m'a proposé de choisir entre 3 lignes vides !

Je dois rater quelque chose, tu l'utilises comment ?

Ça fait plusieurs fois que je vois passer fzf et fzy et que je me dis que je devrais tester. Un avis sur pourquoi utiliser l'un plutôt que l'autre ?

Dans le .gitignore des projets sur lesquels je fais des recherches, il y a des commentaires, des lignes vides, des **, des / en début de ligne et des négations avec !.

Ça peut ressembler à ça :

# Locales
**/locales/*
!**/locales/en.json

# Default
!.gitkeep

ou à ça :

/cozy-stack*
/debian

Effectivement, grep et ses alternatives peuvent être utiliser dans plusieurs contextes. Personnellement, je l'utilise principalement selon ses 3 formes :

1. Je travaille dans une base de code (disons, celle de LinuxFr.org), je suis le plus souvent à la racine du dépôt et je veux chercher un nom de fonction, de variable, un texte que je veux modifier, etc. dans les fichiers versionnés. Avec ripgrep, c'est facile, c'est rg foo. L'équivalent avec grep, ça doit être quelque chose comme grep -r --color --exclude log/ --exclude tmp/ --exclude uploads/ foo ..

2. Je cherche un motif dans un fichier ou répertoire donné (souvent pour retrouver un fichier config dans /etc dont je me rappelle une entrée mais pas le nom du fichier). Avec ripgrep, ça donne rg menu_entry /etc. Avec grep, c'est quasiment pareil : grep -r --color menu_entry /etc.

3. Enfin, je peux vouloir filtrer la sortie d'une ligne de commande. Avec ripgrep ou grep, pas vraiment de différence, cozy-stack instances ls | [rg|grep] _test | xargs cozy-stack instances rm.

J'ai pendant un temps eu un alias de grep pour faire grep -r --color=auto et avec ça, les cas d'usage 2 et 3 sont équivalents en termes de ligne de commande. Ripgrep est plus rapide, ça peut jouer un peu pour le cas d'usage 2. Je préfère la façon dont ripgrep affiche les résultats, mais les goûts et les couleurs, c'est très subjectif. Pour moi, la vraie différence est sur le cas d'usage 1 : c'est le besoin que je rencontre le plus souvent (je suis développeur) et ripgrep m'apporte un vrai confort. Même avec l'alias de grep, je suis obligé d'exclure les fichiers listés dans le gitignore et d'indiquer le répertoire dans lequel je veux chercher (ripgrep prend le répertoire courant par défaut). Ça m'est arrivé un paquet de fois de taper grep foo et d'attendre pendant plusieurs secondes bêtement pour juste me rendre compte que j'avais oublié de préciser de chercher dans le répertoire courant.

Cela dit que grep fasse cela par défaut serait gênant.

Je peux rater quelque chose, mais à mes yeux, ce n'est gênant que parce que grep existe depuis longtemps, qu'il a été utilisé de plein de manières différentes et que changer le comportement par défaut va casser certains scripts dans des cas particuliers difficiles à identifier à l'avance.

D'abord, parce que grep va perdre du temps à parcourir dans la hiérarchie même si on n'en a pas besoin;

Dans quel cas ça arriverait ? Dans les 3 cas d'usage ci-dessus, grep sans l'alias a cherché dans les mêmes fichiers et répertoires que grep avec l'alias pour ajouter l'option -r (ripgrep a cherché dans un peu moins de fichiers, parce que j'ai d'autres choses que juste tmp/ et log/ dans le .gitignore, mais c'était trop long de tout mettre sur la ligne de commande de grep).

ensuite, je combine souvent grep et find pour sélectionner les fichiers (ou plutôt leur type) à traiter.

Moi aussi, dans le cas d'usage 3, mais je n'ai jamais eu de problème que ce soit avec l'alias de grep ou avec ripgrep à ce sujet. Tu penses à quoi ?

Pour avoir longtemps été sysadmin, j'aime pas trop les alternatives

La plupart des admin/sys que je connais n'aiment pas les alternatives et essayent souvent de travailler avec une configuration proche de celle de base pour bash et vim. Je comprends que lorsque l'on passe souvent d'une machine à l'autre, il est plus efficace de bien connaître les outils par défaut que d'essayer d'avoir de meilleurs défauts.

Je trouve ça grave personnellement qu'une alternative à find se permette d'ignorer des fichiers "silencieusement"…

Mais find lui-même se permet d'ignorer des fichiers silencieusement : par défaut, il ne suit pas les liens symboliques et il saute les deux premières entrées de tous les répertoires (en général, c'est . et .., mais pas sur tous les systèmes de fichiers).

Go n'est pas fait pour ça. Go, c'est pour faire du serveur web applicatif, pas un outils en ligne de commande, même si c'est possible, bien sûr.

Oui, mais Rust n'a pas spécialement été conçu pour ça non plus. Si je me souviens bien, j'avais lu quelques articles il y a quelques années qui vantait Go pour écrire des outils purement en ligne de commande, notamment à cause de la compilation statique des bibliothèques en Go, qui simplifie le déploiement.

Avez-vous expliqué le problème, ici https://blog.golang.org/toward-go2 ?

Oui, mais go2, ce n'est pas pour tout de suite…

Pas du tout, Go ne te garantit pas ça, sauf à ne pas utiliser les pointeurs (et comme les slices et maps utilisent les pointeurs, c'est particulièrement rude). Voici un exemple sans variable globale, avec uniquement de la communication entre goroutines via un channel : https://play.golang.org/p/riJqqpTHso9.

On fait le même traitement sur chaque entrée d'une map, en parallèle sur 3 goroutines. Si tout devait bien se passer, on devrait avoir la même valeur pour toutes les entrées de la map. Or, je viens de lancer et ça m'affiche : map[%!s(int=0):2 %!s(int=4):1 %!s(int=5):1 %!s(int=6):3 %!s(int=8):2 %!s(int=1):2 %!s(int=2):2 %!s(int=3):2 %!s(int=7):3 %!s(int=9):2] (des valeurs différentes).

L'exemple est un peu tiré par les cheveux, mais sur Cozy Cloud, on a déjà eu des problèmes réels en production d'accès concurrents entre plusieurs goroutines sur des structs qui sont passées d'une goroutine à d'autres via des channels.

Par contre, ce que tu décris est vrai en Erlang, qui a des espaces mémoires totalement séparés entre les différents processus légers et fais des copies de données.

Avec go, si on utilise que les channels pour communiquer entre goroutine et pas de lock, il n'y a pas de problème potentiel.

Je suis un développeur confirmé en Go et cette affirmation est fausse. Je passe sur les questions de deadlock ou de fuite de goroutines (ce sont des problèmes potentiels, mais disons que c'est en dehors du cadre du thread safety). Par contre, la communication entre goroutine par un channel ne garantit pas l'absence qu'une écriture dans une goroutine puisse avoir des effets dans une autre goroutine (j'en ai fait plusieurs fois la douloureuse expérience).

Quand on envoie une valeur d'une goroutine à une autre goroutine dans un channel, ça en fait une copie par valeur. Ça veut dire que si on envoie un type simple (un entier ou une chaîne de caractères), on est tranquille, ce qu'on modifie d'un côté n'a pas d'effets de l'autre. Par contre, si on commence à passer des choses plus compliquées, par exemple une struct avec un pointeur vers une autre struct (mais c'est aussi vrai pour les maps ou les slices), les deux goroutines vont avoir une struct (pas la même en mémoire) avec un champ qui pointe sur la même struct. Et, du coup, on se retrouve avec la problématique des accès concurrents à cette struct.

Une solution pour s'en sortir est de faire du deep clone avant d'envoyer sa structure dans le channel. Malheureusement, en Go, ce n'est pas facile à faire (à cause de l'absence de génériques et parce que la réflexion n'a pas accès aux champs privés). On peut faire ça en sérialisant puis désérialisant vers du JSON, mais c'est lent et on perd les champs privés. Et c'est comme ça que pour Cozy Cloud, on s'est retrouvé avec des méthodes Clone à un paquet d'endroits que l'on maintient à la main, avec de temps en temps des erreurs ou oublis.

Il y a quelques années, TermKit était une exploration dans ce sens, mais le projet a été abandonné depuis.

Plus récemment, Upterm (anciennement Black Screen) a l'air de proposer quelque chose dans ce style :

Tilix a l'air de savoir faire ça. Et l'action (Shows the password manager to enable a password to be inserted into the terminal) me fait moins peur d'un point de vue sécurité que la version que tu décris.

Oui, les terminaux des DE populaires ont de l'accélération matérielle graphique mais elle reste plus limitée que celle d'OpenGL. L'auteur d'Alacritty a fait des benchmarks (certes assez basiques) qui montrent qu'il y a une vraie différence de performances entre Alacritty et des terminaux plus classiques. On peut, par contre, se poser la question de savoir si ce gain de performances a un intérêt.

Dans la dépêche, j'ai donné un lien vers https://danluu.com/term-latency/. Il montre que la plupart des terminaux ont une latence (temps entre le moment où on appuie sur une touche et le caractères correspondant apparaît à l'écran) au-dessus de 50ms pour des ordinateurs modernes avec de la charge (compilation en cours par exemple). On sait que 50ms est une latence suffisante pour que l'on ressente du lag dans de la réalité virtuelle ou qu'un changement de page qui prend plus de 100ms dans du web ne soit pas perçu comme instantané. On peut donc supposer que cette latence a de bonnes chances d'influer sur la qualité de frappe au clavier (en tout cas, ceux qui ont déjà tapé des commandes via une connexion ssh lente savent à quel point on fait plus de fautes avec une latence élevée).

A priori, il y a au moins kitty, tilix et Terminology qui savent afficher des images.

Merci, je l'ai ajouté à la dépêche !

Merci, je l'ai ajouté à la dépêche !

Merci, j'ai ajouté les deux liens à la fin de la dépêche.

Merci, je n'avais pas entendu parler de Tilix alors qu'il a l'air très bien comme terminal. Je l'ai ajouté à la dépêche et je vais l'essayer.

Merci, j'ai ajouté Gnome Terminator à la dépêche !

Merci, j'ai complété la dépêche avec ces terminaux !

Merci, j'ai ajouté cool-retro-term à la liste !