Pour le remplacement automatique, il y a peut être quelque chose à faire avec les abbréviations, mais ça n'a pas l'air simple pour ton exemple du tiret. Tu pourrais avec:
:abbreviate -- —
dire que tu remplaces deux tirets par un tiret long, mais cela demande donc une connaissance de l'utilateur. M'enfin s'il utilise vim il a déjà appris le plus gros :)
J'avais déjà vu ce genre de comparaison mais pour quelque chose de plus parlant je pense: parler en distance uniquement plutôt qu'en distance. C'était à un GUADEC je crois, mais je n'arrive plus à retrouver. Mais en gros tu avais des cercles concentriques sur un planisphère pour montrer la distance à parcourir pour aller chercher l'information (cette distance étant intuitivement liée au temps: plus c'est loin plus c'est long d'y aller).
Tu te retrouvais donc, comme toi, à accéder au cache sur un papier sur ton bureau, ou alors à devoir aller à l'autre bout du monde récupérer l'information.
Il y a aussi (précis mais pas assez visuel à cause des changements d'échelle je trouve) :
En fait ça ne marchera pas pour plusieurs raisons.
Raison n°1: le mauvais type de guillemet est utilisé
Il faut différencier (je pars du principe que tu as un clavier azerty):
` (backquote, AltGr+7 sur ton clavier)
' (guillemet simple, sur la touche 4 du clavier)
" (guillemet double, sur la touche 3 du clavier)
Je n'aime pas le backquote (guillemet inversé) parce que quand on débute on ne voit pas la différence avec le guillemet simple. La notation $(commande) est équivalente à `commande` et plus compréhensible à mon sens.
La commande man te donne des infos sur une commande. man tar te dira donc à quoi correspondent les lettres qui suivent (pour casses le suspense, ce sont des options, à toi de regarder le manuel pour savoir ce que fait la commande tar et à quoi correspondent ces options)
Conclusion
Il y a de fortes chances que tu te sois gourré en tapant ta première commande:
for i in 'ls..lesDonnees/*.val'
(au passage il manque aussi un slash).
Je ne pense pas me tromper en disant qu'il doit être écrit sur ton papier plutôt:
Idem, un coup de wget, pas de fichier .reg. Les fichiers en eux même sont juste des fichiers contenant des données aléatoires. Il y en a un seul qui contient la chaine "reg", et c'est par pur hasard. Donc on oublie le coup du fichier qui contient le lien vers le fichier .reg… Aucun fichier qui contient la chaîne "HKEY" non plus. Il y a 30 fichiers que "file" ne voit pas comme étant de l'HTML, et rien de lisible.
C'est un exo censé être facile ou bien la stéganographie est au programme ? _^
Si ces logiciels ont besoin d'un environnement à eux, mais que tu ne veux pas polluer ton shell avec leur environnement, alors fais juste un script qui sert de wrapper. Il chargera l'environnement de tes autres scripts avant de le appeller.
Si au contraire tu veux toujours avoir cet environnement dans ton shell courant, alors fais un source cao-scripts/environnement-logiciel dans ton $HOME/.bashrc.
Dans tous les cas, l'environnement et l'appel du programme final sont deux choses distinctes. Il faut les découpler, pour que n'importe qui puisse charger un environnement, potentiellement différent.
Arf, oui j'avais oublié cette limitation. Je n'utilise que des applis python sur la machine où j'ai fait la modification, et les dernières versions de Python 2.7 et Python >= 3.6 gèrent les chemins longs, du coup ça "just works". Mais rdiff-backup est libre (GPL-2.0-or-later), et, même si le recompiler ne doit pas être une partie de plaisir, le manifest peut être patché.
We offer single-file binaries that do not require installing anything - you can just run them on these platforms:
Linux
Mac OS X
FreeBSD
OpenBSD and NetBSD (no xattrs/ACLs support or binaries yet)
Cygwin (experimental, no binaries yet)
Linux Subsystem of Windows 10 (experimental)
"Pas de binaire tout-en-un pour Windows" c'est différent de "pas de version Windows". borgbackup est disponible sur PyPI, donc tu peux installer chocolatey par exemple, puis taper dans un shell Windows:
choco install python3 # il faut répondre "yes" pour autoriser l'exécution des scripts
# Ici, il faudra peut être fermer et réouvrir le shell,
# ou faire un "reloadenv" pour avoir les variables d'environnement
# python
virtualenv backup-tools # On va faire propre et créer un environnement virtuel
backup-tools\Scripts\activate.cmd # On rentre dans l'environnement virtuel
pip install borgbackup # On installe borgbackup
On peut autoriser les chemins supérieurs à 256 caractères depuis (au moins) Windows 10 et Windows Server 2016.
Tu as une clé de registre à activer: https://stackoverflow.com/a/52007527/518853
Tu as donc peut être une chance que rdiff-backup fonctionne ;).
Je vois le problème, mais je ne sais pas si i786 c'est "la" solution. En tout cas, si déjà sur les mécanisme d'upgrade on vérifiait que le matériel que tu t'apprêtes à mettre à jour est toujours géré par la version n+1 de la distrib, ce serait déjà autant de personnes en moins qui flingueraient leur config pour rien.
le kernel n'est plus stable parce que pas assez testé sur 32-bits
les paquets 32 bits sont utilisés surtout en parallèle des paquets 64 bits sur des systèmes 64 bits
Donc pour faire du 32 bits, ils se basent sur le jeu d'instruction 32 bits que les premiers CPU 64 bits comprenaient. Ensuite des gens mettent à jour des vieilles machines, et paf le chat.
Ensuite, que ce soit Fedora, Mageia ou autre, i*86 c'est trop "grosse maille". Si le système te propose une mise à jour que tu acceptes sans vérifier systématiquement à chaque release que ton CPU est bien toujours géré, bin tu peux faire la mise à jour et te retrouver avec un système potentiellement cassé.
Si quelqu'un à un lien pour Mageia, je suis preneur. On m'a orienté vers le fichier boot/config-{version} ou la commande rpm --eval %configure mais il y a forcément un rpmrc équivalent chez mageia, mais je ne sais pas où il se trouve non plus.
je ne demande pas aux distribs de compiler sans SSE2, les nouvelles machines doivent pouvoir tirer partie des optimisations
en pratique, je n'ai eu des soucis qu'avec 2 composants utilisant réellement SSE2 (flash et libflac), "tout compiler pour quelques machines perdues" est donc hors de propos
Cependant, par expérience, ces machines sont encore utilisables (la mienne en tout cas). J'ai racheté un portable plus récent, mais mon vieux PC fixe est le seul à avoir un lecteur CD. J'ai un autre vieux PC récupéré, à base de CPU intel mais lui c'est la carte graphique qui ne gère pas GNOME 3. Même problème, les pre-requis minimum, sont "flous". En gros pour savoir, faut essayer.
Je suis capable de recompiler les programmes qui posent problème. Mais les distribs ne communiquent pas trop sur les pré-requis matériels, changent plus ou moins silencieusement des flags de compilation importants, tout en conservant la même appellation "i686" qui a toujours fait fonctionner nos vieilles machines.
Quand tu casses la compatibilité binaire d'un logiciel, une bonne pratique est de changer de version majeure. Là tu romps la compatibilité mais tu t'appelles toujours i686, et les gens passent du temps à déboguer parce que ça a toujours fonctionné chez eux par le passé. Cela devrait être possible de déduire quelles architectures matérielles exactement sont gérées à partir des flags de compilation. Il faudrait juste les mettre plus en avant plutôt que promouvoir un "i686" qui n'a plus beaucoup de sens.
Le problème n'est pas que là. Ce qui me dérance c'est plutôt que les distribs décident de ne plus prendre plus en charge SSE2, continuent à faire des paquets i686, mais ne communiquent pas sur le fait que ça ne marchera plus pour certaines personnes. L'utilisateur final ne sait pas non plus à partir de quelle version de distrib exactement ces architectures ne sont plus gérées (ou alors l'information m'a échappé).
Pourtant en pratique, j'ai eu le problème avec très peu d'applications: d'abord le plugin flash (mais lui a l'excuse d'être propriétaire), puis libflac 1 ou 2 ans plus tard.
Ah, c'était dans libflac le problème. Un autre soucis c'est de savoir avec quels flags d'architecture sont compilés les distros, pour pouvoir savoir chaque distrib est vraiment compatible.
[^] # Re: Ha ouais, quand même...
Posté par liberforce (site web personnel) . En réponse au journal Une backdoor vient d’être trouvée dans un paquet npm connu. Évalué à 10.
Pas d'accord. Le logiciel libre, c'est la licence, point barre.
La manière dont tu gères une communauté d'utilisateurs, c'est autre chose.
[^] # Re: Comparaison parlante
Posté par liberforce (site web personnel) . En réponse au journal Le microprocesseur, ce monstre de puissance qui passe son temps à attendre. Évalué à 8. Dernière modification le 23 novembre 2018 à 15:49.
C'est ce que je me dis toujours quand je compte sur les 3+2 doigts de chacune de mes 1+1 mains.
[^] # Re: Éditeur ?
Posté par liberforce (site web personnel) . En réponse au message éditeur texte ou markdown aidant à la conformité à la langue française. Évalué à 4.
Pour mettre en évidence des caractères, Vim + un
set listchars
?http://vimcasts.org/transcripts/1/en/
Pour le remplacement automatique, il y a peut être quelque chose à faire avec les abbréviations, mais ça n'a pas l'air simple pour ton exemple du tiret. Tu pourrais avec:
dire que tu remplaces deux tirets par un tiret long, mais cela demande donc une connaissance de l'utilateur. M'enfin s'il utilise vim il a déjà appris le plus gros :)
# Comparaison parlante
Posté par liberforce (site web personnel) . En réponse au journal Le microprocesseur, ce monstre de puissance qui passe son temps à attendre. Évalué à 8.
J'avais déjà vu ce genre de comparaison mais pour quelque chose de plus parlant je pense: parler en distance uniquement plutôt qu'en distance. C'était à un GUADEC je crois, mais je n'arrive plus à retrouver. Mais en gros tu avais des cercles concentriques sur un planisphère pour montrer la distance à parcourir pour aller chercher l'information (cette distance étant intuitivement liée au temps: plus c'est loin plus c'est long d'y aller).
Tu te retrouvais donc, comme toi, à accéder au cache sur un papier sur ton bureau, ou alors à devoir aller à l'autre bout du monde récupérer l'information.
Il y a aussi (précis mais pas assez visuel à cause des changements d'échelle je trouve) :
[^] # Re: Concevoir un enfant ?
Posté par liberforce (site web personnel) . En réponse au journal Le microprocesseur, ce monstre de puissance qui passe son temps à attendre. Évalué à 6. Dernière modification le 22 novembre 2018 à 16:31.
Douche comprise.
[^] # Re: decomposer, comprendre et recomposer
Posté par liberforce (site web personnel) . En réponse au message Besoins d'aide sur deux commandes. Évalué à 7.
En fait ça ne marchera pas pour plusieurs raisons.
Raison n°1: le mauvais type de guillemet est utilisé
Il faut différencier (je pars du principe que tu as un clavier azerty):
`
(backquote, AltGr+7 sur ton clavier)'
(guillemet simple, sur la touche 4 du clavier)"
(guillemet double, sur la touche 3 du clavier)Je n'aime pas le backquote (guillemet inversé) parce que quand on débute on ne voit pas la différence avec le guillemet simple. La notation
$(commande)
est équivalente à`commande`
et plus compréhensible à mon sens.Pour comprendre un peu mieux, je te conseille donc la lecture du Guide avancé d'écriture des scripts Bash, et notamment la partie sur les guillemets.
Raison n°2: les espaces servent de séparateur
Cette commande n'est pas valide:
Celle là oui:
Raison n°3: man est ton ami (aka RTFM)
La commande
man
te donne des infos sur une commande.man tar
te dira donc à quoi correspondent les lettres qui suivent (pour casses le suspense, ce sont des options, à toi de regarder le manuel pour savoir ce que fait la commande tar et à quoi correspondent ces options)Conclusion
Il y a de fortes chances que tu te sois gourré en tapant ta première commande:
(au passage il manque aussi un slash).
Je ne pense pas me tromper en disant qu'il doit être écrit sur ton papier plutôt:
Tu devrais à présent voir les différences.
# Tu retardes...
Posté par liberforce (site web personnel) . En réponse au lien Linus de nouveau aux commandes. Évalué à 3. Dernière modification le 20 novembre 2018 à 18:09.
Ça fait déjà un mois qu'il est de retour:
https://lkml.org/lkml/2018/10/23/288
[^] # Re: Précision
Posté par liberforce (site web personnel) . En réponse au message fichier caché dans un URL. Évalué à 5.
Idem, un coup de wget, pas de fichier .reg. Les fichiers en eux même sont juste des fichiers contenant des données aléatoires. Il y en a un seul qui contient la chaine "reg", et c'est par pur hasard. Donc on oublie le coup du fichier qui contient le lien vers le fichier .reg… Aucun fichier qui contient la chaîne "HKEY" non plus. Il y a 30 fichiers que "file" ne voit pas comme étant de l'HTML, et rien de lisible.
C'est un exo censé être facile ou bien la stéganographie est au programme ? _^
# Un peu vague, mais bon...
Posté par liberforce (site web personnel) . En réponse au message sourcer un script qui n'est pas dans le répertoire courant et sans ajouter son path. Évalué à 4.
Si ces logiciels ont besoin d'un environnement à eux, mais que tu ne veux pas polluer ton shell avec leur environnement, alors fais juste un script qui sert de wrapper. Il chargera l'environnement de tes autres scripts avant de le appeller.
Si au contraire tu veux toujours avoir cet environnement dans ton shell courant, alors fais un
source cao-scripts/environnement-logiciel
dans ton$HOME/.bashrc
.Dans tous les cas, l'environnement et l'appel du programme final sont deux choses distinctes. Il faut les découpler, pour que n'importe qui puisse charger un environnement, potentiellement différent.
# Search Engine 101
Posté par liberforce (site web personnel) . En réponse au message Cherche aide pour programmer . Évalué à 3.
Et sinon, comment tu as atterri sur linuxfr si tu ne sais pas utiliser un moteur de recherche ?
Cette recherche:
https://www.google.com/search?q=python+tutoriel
T'aurait permis de trouver (entre autres) ceci:
https://openclassrooms.com/fr/courses/235344-apprenez-a-programmer-en-python
[^] # Re: Limite MAX_PATH à 256 caractères
Posté par liberforce (site web personnel) . En réponse au journal De la sauvegarde sous windows. Évalué à 2.
Arf, oui j'avais oublié cette limitation. Je n'utilise que des applis python sur la machine où j'ai fait la modification, et les dernières versions de Python 2.7 et Python >= 3.6 gèrent les chemins longs, du coup ça "just works". Mais rdiff-backup est libre (GPL-2.0-or-later), et, même si le recompiler ne doit pas être une partie de plaisir, le manifest peut être patché.
Voilà le patch pour Python 3.6, ça devrait être transposable:
https://hg.python.org/cpython/rev/26601191b368
La 1.2.8 (dernière stable) est disponible ici:
http://svn.savannah.nongnu.org/svn/rdiff-backup/tags/r1-2-8/rdiff-backup/
La 1.3.3 (version de développement) est disponible ici:
http://svn.savannah.nongnu.org/svn/rdiff-backup/tags/r1-3-3/rdiff-backup/
Sinon tu as un import git ici:
https://github.com/sol1/rdiff-backup
[^] # Re: borgbackup et Windows
Posté par liberforce (site web personnel) . En réponse au journal De la sauvegarde sous windows. Évalué à 2.
argh, c'est
activate.bat
, pasactivate.cmd
.[^] # Re: Lapin compris
Posté par liberforce (site web personnel) . En réponse au journal scraplap, pour mouler offline. Évalué à 3.
Profites-en bien, il me semble qu'ils vivent leurs dernières heures.
# borgbackup et Windows
Posté par liberforce (site web personnel) . En réponse au journal De la sauvegarde sous windows. Évalué à 4. Dernière modification le 06 novembre 2018 à 12:01.
"Pas de binaire tout-en-un pour Windows" c'est différent de "pas de version Windows". borgbackup est disponible sur PyPI, donc tu peux installer chocolatey par exemple, puis taper dans un shell Windows:
# Limite MAX_PATH à 256 caractères
Posté par liberforce (site web personnel) . En réponse au journal De la sauvegarde sous windows. Évalué à 4.
On peut autoriser les chemins supérieurs à 256 caractères depuis (au moins) Windows 10 et Windows Server 2016.
Tu as une clé de registre à activer: https://stackoverflow.com/a/52007527/518853
Tu as donc peut être une chance que rdiff-backup fonctionne ;).
[^] # Re: Espace disque partagé...
Posté par liberforce (site web personnel) . En réponse au journal Flatpak. Évalué à 2.
Tu as jeté un coup d'oeil à conan ?
# Lien des release notes
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 7. Dernière modification le 31 octobre 2018 à 15:22.
Le lien vers les release notes pointe sur la racine de toutes les release notes.
Là on veut f29, pour avoir quelque chose de stable dans le temps il vaudrait donc mieux pointer vers https://docs.fedoraproject.org/fr-FR/fedora/f29/release-notes/
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 5.
Je vois le problème, mais je ne sais pas si i786 c'est "la" solution. En tout cas, si déjà sur les mécanisme d'upgrade on vérifiait que le matériel que tu t'apprêtes à mettre à jour est toujours géré par la version n+1 de la distrib, ce serait déjà autant de personnes en moins qui flingueraient leur config pour rien.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 7.
Et le bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1592212
Et la proposition à son origine:
https://fedoraproject.org/wiki/Changes/Update_i686_architectural_baseline_to_include_SSE2
Le constat pour Fedora est donc:
Donc pour faire du 32 bits, ils se basent sur le jeu d'instruction 32 bits que les premiers CPU 64 bits comprenaient. Ensuite des gens mettent à jour des vieilles machines, et paf le chat.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 3.
Voilà le commit qui active SSE2 par défaut pour i686:
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/a5c98437e2aabe7a75fc13099a41ed3306587401
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 1.
Au passage les iso Mageia 6 sont en "i586". Le guide d'empaquetage contient ceci:
Ça n'aide pas à la compréhension.
Ensuite, que ce soit Fedora, Mageia ou autre, i*86 c'est trop "grosse maille". Si le système te propose une mise à jour que tu acceptes sans vérifier systématiquement à chaque release que ton CPU est bien toujours géré, bin tu peux faire la mise à jour et te retrouver avec un système potentiellement cassé.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 3. Dernière modification le 31 octobre 2018 à 14:37.
Super, merci !
Si quelqu'un à un lien pour Mageia, je suis preneur. On m'a orienté vers le fichier
boot/config-{version}
ou la commanderpm --eval %configure
mais il y a forcément un rpmrc équivalent chez mageia, mais je ne sais pas où il se trouve non plus.[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 9.
Alors soyons clairs:
Cependant, par expérience, ces machines sont encore utilisables (la mienne en tout cas). J'ai racheté un portable plus récent, mais mon vieux PC fixe est le seul à avoir un lecteur CD. J'ai un autre vieux PC récupéré, à base de CPU intel mais lui c'est la carte graphique qui ne gère pas GNOME 3. Même problème, les pre-requis minimum, sont "flous". En gros pour savoir, faut essayer.
Je suis capable de recompiler les programmes qui posent problème. Mais les distribs ne communiquent pas trop sur les pré-requis matériels, changent plus ou moins silencieusement des flags de compilation importants, tout en conservant la même appellation "i686" qui a toujours fait fonctionner nos vieilles machines.
Quand tu casses la compatibilité binaire d'un logiciel, une bonne pratique est de changer de version majeure. Là tu romps la compatibilité mais tu t'appelles toujours i686, et les gens passent du temps à déboguer parce que ça a toujours fonctionné chez eux par le passé. Cela devrait être possible de déduire quelles architectures matérielles exactement sont gérées à partir des flags de compilation. Il faudrait juste les mettre plus en avant plutôt que promouvoir un "i686" qui n'a plus beaucoup de sens.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 4.
Le problème n'est pas que là. Ce qui me dérance c'est plutôt que les distribs décident de ne plus prendre plus en charge SSE2, continuent à faire des paquets i686, mais ne communiquent pas sur le fait que ça ne marchera plus pour certaines personnes. L'utilisateur final ne sait pas non plus à partir de quelle version de distrib exactement ces architectures ne sont plus gérées (ou alors l'information m'a échappé).
Pourtant en pratique, j'ai eu le problème avec très peu d'applications: d'abord le plugin flash (mais lui a l'excuse d'être propriétaire), puis libflac 1 ou 2 ans plus tard.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 1.
Ah, c'était dans libflac le problème. Un autre soucis c'est de savoir avec quels flags d'architecture sont compilés les distros, pour pouvoir savoir chaque distrib est vraiment compatible.