Matthieu Moy a écrit 3251 commentaires

Attention, « mémoire occupée » peut vouloir dire beaucoup de choses différentes sur un système moderne. Qu'as-tu utilisé pour obtenir tes chiffres ? Que donne la commande vmstat ?

Et j'anticipe sur l'explication : en quoi est-ce problématique que ta RAM soit utilisée ;-) ?

Oui, c'est clair que :

« Les utilisateurs qui concèdent un accès à des services tiers prennent le risque que leurs messages soient scannés »

C'est quand même un peu une tautologie du style (modulo un passage dans le dictionnaire des synonymes).

Yaka désinstaller l'ancienne et réinstaller la nouvelle, non ?

# dpkg --force-depends --remove libc6 
# dpkg -i libc6*.deb 
bash: /usr/bin/dpkg: No such file or directory
# ls
bash: /bin/ls: No such file or directory

Argh !

J'avais posé plus ou moins la même question il y a un moment :

https://linuxfr.org/forums/general-cherche-logiciel/posts/auto-hebergement-de-galeries-photos

Finalement je suis sur Piwigo, hébergé sur piwigo.com. C'est assez loin d'être parfait, mais c'est quand même sympa d'avoir une solution basée sur du logiciel libre et hébergé par une PME et non une GAFAM. Techniquement le gros point fort est la personalisabilité. J'avais d'ailleurs écrit une dépêche là dessus :

https://linuxfr.org/news/piwigo-2-7-un-chez-soi-pour-vos-photos

J'étais passé un peu vite sur Owncloud/Nextcloud, mais ce sont aussi des solutions très intéressantes. En gros, un dropbox libre.

Nan, avec GitLab, c'est totalement impossible que les backups ne soient pas utilisables.

[[ est non-POSIX par contre (donc pas dispo sous dash, qui est souvent le shell derrière /bin/sh). Dans POSIX il y a juste [ et test.

Et si le but est juste d'afficher le nom du fichier sans fioritures :

echo **/toto/*tata*

HSTS indique juste au navigateur client qu'il doit utiliser la version HTTPS du site, pour une certaine durée, il n'y a pas d'information de clé.

Pas de notion de clé, mais une attaque MITM peut remplacer la version HTTP par ce qu'il veut. C'est moins grave que pour une clé parce que l'attaque est visible (l'URL reste en http://, pas de cadenas dans la barre d'URL, …), mais pour un utilisateur peu attentif ou peu compétent, il y a pas mal de dégâts à faire au moment de la première utilisation.

Après, c'est pas pire que rien du tout : un serveur qui ne répond pas sur le port 80 pourrait se faire attaquer de la même manière qu'un HSTS.

ma dernière expérience avec bash date d'il y a quelques années déjà alors ils ont certainement fait des progrès entre-temps

Donc tu es super bien placé pour écrire des choses comme « Et encore tu es poli: comparer les deux n'a à moin avis presqu'aucun sens. », hein …

Et tout d'un coup, magie: git complète, docker complète

cf. mon autre message, sur une Debian oldstable sortie il y a 3 ans, git complete aussi très bien. Docker existait à peine à l'époque donc sans grande surprise la complétion intelligente n'existait pas encore pour docker mais elle a bien sûr été ajoutée depuis.

git affiche sa branche dans le prompt

Sauf qu'on comparait la complétion intelligente, là. Et bon, le nom de branche dans le prompt, c'est pas dans la config par défaut de zsh (peut-être de oh-my-zsh par contre), et c'est pas comme si c'était compliqué à ajouter sous bash.

Bref, perso, j'ai pas vu d'exemple pour supporter ton affirmation initiale, qui était pourtant bien affirmative …

Encore une fois, j'adore zsh, mais faudrait peut-être se renseigner un peu avant de pourrir bash sans le connaître.

J'ai remarqué la même chose, mais chez moi au moins c'est un comportement de zsh et pas du terminal (ça marche dans plusieurs terminaux avec zsh, mais pas avec bash).

Du coup tu fais comment pour installer un logiciel sur ta machine ?

Bon, après, on est d'accord que zsh powers quand même, hein ;-).

Avec bash, il faut le faire 2 fois.

Dans la config par défaut, oui. Mais si tu cherches un peu, tu ne devrais pas mettre plus longtemps que moi à trouver show-all-if-ambiguous dans la config de bash.

Notamment, j'utilise Debian stable

J'ai reproduit les manips de mon message en oldstable (jessie), après avoir effacé ~/.bash*. Tout marche out-of-the-box aussi.

J'ai pourtant lourdement insisté que c'est le comportement ici, que j'ai, et que ça peut varier en fonction de systèmes

Moi, dans ton premier message, j'ai lu « franchement, elle n'a rien a voir avec celle de zsh niveau puissance », qui m'avait l'air un poil plus général que « je n'arrive pas à faire marcher la complétion chez moi » quand même …

Tu te plains à la fois de la config par défaut qui n'est pas celle que tu voudrais, et de ta config qui ne fait pas quelque chose qui marche nickel par défaut, c'est un peu paradoxal.

J'utilise d'habitude zsh donc mon bash n'est pas particulièrement customizé (Ubuntu 16.04). J'ai essayé :

Chez moi (j'insiste, chez moi), bash ne semble pas pouvoir auto-compléter efficacement un script ./configure, zsh si.

$ ./configure --
--bindir=                  --psdir=
--cache-file=              --quiet
--config-cache             --runstatedir=
--datadir=                 --sbindir=
--datarootdir=             --sharedstatedir=
[...]

Idem pour make

$ (echo foo1:; echo foo2:)>Makefile
$ make foo
foo1  foo2  

cmake.

$ cmake -
-A                    --help-manual         --no-warn-unused-cli
--build               --help-manual-list    -P
-C                    --help-module         --system-information
--check-system-vars   --help-module-list    -T
[...]
$ cmake -D
-DCMAKE_AR
-DCMAKE_BUILD_TYPE
-DCMAKE_COLOR_MAKEFILE
-DCMAKE_CXX_COMPILER
-DCMAKE_CXX_FLAGS
[...]

il me semblait qu'il ne le faisait pas, mais apparemment ça a été ajouté. Par contre, dieux que c'est lent, et il faut double-tabuler…

Chez moi, il faut double-tabuler en cas d'ambiguité et c'est pas spécialement lent (il me sort quasi-instantanément Display all 10244 possibilities? (y or n)).

À mon avis tu as un truc cassé dans ta config.

J'aime bien zsh, mais de là à prétendre que la complétion intelligente de bash est incomparablement moins bonne, c'est peut-être pousser le bouchon un peu loin quand même.

Moi j'en ai 4, c'est de pire en pire !

Ceci dit, bash a aussi une complétion intelligente, et elle est activée dans /etc/bash.bashrc (. /etc/bash_completion ou quelque chose qui ressemble) par la plupart des distribs. Celle de zsh est plus avancée, mais bash est déjà pas mal du tout.

Une autre killer-feature qui m'avait fait passer à ZSH était le globbing avec **, mais là aussi bash sait faire aussi maintenant.

Je regarderai du côté de mu (https://www.djcbsoftware.nl/code/mu/) pour récupérer les mails aux bonnes dates (rapidement en plus !). Après si tu es sûr que l'adresse est sur une seule ligne, grep -m 1 '^From: ' | sed 's/From: //' devrait faire l'affaire. Si tu veux plus évolué, regarde un langage de script genre perl ou python et les libs qui vont bien (email.parser pour Python ?).

À noter que comme souvent, les notes de sorties officielles sont complètes mais pas hyper digestes pour les non-initiés. Il y a un article plus didactique sur le blog de GitHub : https://blog.github.com/2018-04-05-git-217-released/

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.

Plus précisément : ça ne cherche que dans les fichiers trackés par Git. En général, ce sont tous les fichiers sauf ceux ignorés par un .gitignore, mais on peut tout à fait tracker des fichiers qui sont dans .gitignore (git add -f), et avoir des fichiers non-trackés et non-ignorés (ceux qui apparaissent dans la section Untracked files) de git status.

Bref, si on veut reproduire ça avec des scripts et sans git grep, le plus proche serait un truc à base git ls-files | xargs grep, mais pas un script qui parse .gitignore.

Solution à tous tes problèmes : git grep. C’est installé sur toutes les machines bien administrées, non ;-) ?

Plus sérieusement, en temps que sysadmin je comprends ta position. Mais en temps que développeur ce sont des outils relativement faciles à installer (et là j'enlève le smiley sur le fait que git grep doit être présent, si c'est pas lui c'est hg grep), et c'est bien plus que 0,0001 seconde de gagnée d'avoir un outil qui ignore les fichiers générés (c'est long de chercher du texte dans des .o et .so, et c'est pénible d'avoir des matchs dans les *~ et autres fichiers de backups !).

Je pense qu'il faisait allusion à https://linuxfr.org/news/seconde-mise-en-demeure-pour-l-association-linuxfr

Oui, et j'ai posté mon commentaire avant d'avoir vu https://linuxfr.org/forums/general-general/posts/mise-en-demeure-3-0.

Je ne sais pas si c'est volontaire (si c'est le cas, j'ai trouvé ça très fin de la part de l'auteur !), mais cette dépêche contient à peu près tous les éléments de langages qui avaient été considérés comme plagiat dans le billet précédent (dates du vote, méthode de vote, et une conclusion qui souhaite bonne chance au(x) candidats).

Si je compare cette news au billet de F. Gallaire (https://fgallaire .flext.net/quel-dpl-debian-project-leader-pour-2018/ avec un espace en trop pour ne pas contribuer au google-ranking de ce monsieur), y'a quand même « None of the above » qui est clairement un plagiat de l'un ou de l'autre ;-).

Vous n'avez pas peur de vous prendre un procès avec une news comme ça ?

Un début d'explication dans ce journal : https://linuxfr.org/users/windu2b/journaux/l-indigne-bronsonise

C'est pas hyper clair pour moi (qui suis nouveau sur ce forum), mais ça a l'air d'être écrit par quelqu'un de sérieux.

Sur ton schéma, le pavé en bas à droite n'existe pas. C'est du vide.

Ce n'est pas grave.

Le point situé 8 mètres sous le point N est directement connecté au point situé 23 mètre à droite du point P. Soit un trajet de 31 mètres.

Si on choisi de suivre l'horizontale puis la verticale, mais la le but est de prendre le chemin le plus court donc de suivre l'hypotenuse, qui est plus courte tout en passant par des morceaux de la figure qui existent.