Précision sur l'action d'une commande

Version imprimable

16/10/2023, 09h45
Mr ZEE

Précision sur l'action d'une commande

Bonjour,

Sur cette commande, enfin cette proto-commande, où on écrase le contenu du dossier "cible" et où "cible" contient à sa racine plusieurs dossiers et 2 fichiers :

Code:

...overwrite /rep00/rep01/cible/\*/\*

Je n'arrive pas à expliquer précisément l'action de

Code:

\*/\*
18/10/2023, 22h53
Sve@r

Bonjour

Citation:

Envoyé par Mr ZEE

Je n'arrive pas à expliquer précisément l'action de

Code:

\*/\*

C'est un simple backslash permettant de ne pas transformer le caractère "*". On veut donc le fichier se situant dans le dossier "*" (littéralement "étoile") et dont le nom c'est là aussi littéralement "*".
Mais si on écrit "*/*" le shell transforme ces caractères pour leur faire signifier "tout dossier dont le nom est tout caractère et contenant tout fichier dont le nom est tout caractère" ce qui équivaut à "tous les fichiers de tous les dossiers" tout court. Donc il faut neutraliser leur action donc backslash.
On aurait pu écrire aussi ...overwrite "/rep00/rep01/cible/*/*" entre quotes ce qui a la même action et qui permet donc d'éviter le backslash.

PS: ce sont là des noms peu judicieux. Celui qui a créé ces fichiers était soit un petit plaisantin, soit un type pas super fûté.
20/10/2023, 10h40
Mr ZEE

Citation:

Envoyé par Sve@r

PS: ce sont là des noms peu judicieux. Celui qui a créé ces fichiers était soit un petit plaisantin, soit un type pas super fûté.

Les noms des dossiers sont à titre indicatif et un prétexte pour établir un chemin, rien de plus :)

Merci pour ta réponse.
Donc on est bien d'accord pour constater que cette proto-commande par exemple :

Code:

...overwrite /rep00/rep01/cible/*

Ne peut pas fonctionner, parce qu'elle est incomplète.

Qu'est ce que cela donne pour cette proto-commande ? :

Code:

...overwrite '*'
20/10/2023, 11h10
Sve@r
Citation:

Envoyé par Mr ZEE

Donc on est bien d'accord pour constater que cette proto-commande par exemple :

Code:

...overwrite /rep00/rep01/cible/*

Ne peut pas fonctionner, parce qu'elle est incomplète.

Je ne comprends pas ce que tu entends par "incomplète". En quoi est-elle incomplète ? Le nom "étoile" sera remplacé par "tous les fichiers présents dans /rep00/rep01/cible" donc de là on aura bien des noms de fichiers. Si maintenant la commande attend un nom et qu'elle reçoit des noms effectivement elle ne sera pas dans un schéma prévu et refusera l'action (exemple cp /etc/* toto avec "toto" qui n'est pas dossier). Mais d'un point de vue purement shell, elle est parfaitement complète.
En fait il faut bien comprendre que la commande, elle, ne reçoit pas l'étoile. C'est le shell qui fait l'intermédiaire qui s'occupe de transformer l'étoile en "tous les fichiers présents". Si tu écris un code C et que tu affiches argv[1] puis tu lui envoies "/etc/*" le programme affichera "/etc/adduser.conf"

Citation:

Envoyé par Mr ZEE

Qu'est ce que cela donne pour cette proto-commande ? :

Code:

...overwrite '*'

Pourquoi tu n'essayes pas toi-même pour te faire ta propre expérience ?
- echo /etc/\*
- echo "/etc/*"
- echo '/etc/*'
- echo /etc/*
Le caractère "quotte simple" (ou apostrophe) a dans ce cas précis le même comportement => il annule l'interprétation. Son comportement sera différent de la quotte double lorsqu'il s'agira de variables (la quotte simple annule tout donc y compris le dollar de la variable, la quotte double annule tout sauf certains éléments dont fait partie le dollar => afficher '$HOME' sera différent d'afficher "$HOME").
21/10/2023, 13h06
Mr ZEE

Citation:

Envoyé par Sve@r

Je ne comprends pas ce que tu entends par "incomplète". En quoi est-elle incomplète ?

Franchement je m'attendais à pire ;) : je te dois une explication :oops:

J'aimerai tester une distro en rolling release et je me suis mis à explorer Manjaro. Et j'ai chopé un post sur leur forum français qui évoque un problème de mise à jour (pas inintéressant pour du rolling release...).
La maj ne s’exécute pas à cause du contenu du dossier des paramètres régionaux et en réponse on propose dans un premier temps ceci (où -Syu est la commande de maj standard d'après ce que j'ai lu) :

Code:

sudo pacman -Syu --overwrite /usr/lib/locale/*

J'ai trouvé ça un peu hard, mais bon... Et ça n'a pas fonctionné.
En réponse :

Code:

sudo pacman -Syu --overwrite '*'

Qui n'a pas été utilisé et que j'ai trouvé bizarre, mais bon je n'ai pas le niveau non plus...
Puis il y a eu ceci :

Code:

sudo pacman -Syu glibc-locales --overwrite /usr/lib/locale/\*/\*

Qui a résolu le problème et qui du même coup m'a interpellé sur la fin de la commande des \*/\*, sans compter que le topic à l'air un peu lunaire.

Ceci dit je te remercie grandement pour tes explications toujours aussi riches et passionnantes :ccool:
21/10/2023, 13h34
Sve@r

Citation:

Envoyé par Mr ZEE

Code:

sudo pacman -Syu --overwrite /usr/lib/locale/*

J'ai trouvé ça un peu hard, mais bon... Et ça n'a pas fonctionné.
En réponse :

Code:

sudo pacman -Syu --overwrite '*'

Qui n'a pas été utilisé et que j'ai trouvé bizarre, mais bon je n'ai pas le niveau non plus...
Puis il y a eu ceci :

Code:

sudo pacman -Syu glibc-locales --overwrite /usr/lib/locale/\*/\*

Alors...

La première ...--overwrite /usr/lib/locale/* va s'adresser à tout le contenu du dossier "/usr/lib/locale" (tous les fichiers et dossiers (je fais la distinction mais en réalité un dossier n'est qu'un fichier particulier) situés juste sous le dossier "/usr/lib/locale"). Effectivement ça semble hard mais sait-on jamais, peut-être qu'effectivement il faut appliquer l'action à tout le contenu de ce dossier.

La seconde ...--overwrite '*' (on ne parle plus de "/usr/locale" ???) fait là référence à la chaine littérale "étoile". Mais peut-être que c'est voulu, pour que la commande puisse utiliser cette étoile en interne dans son action. Il y a un exemple analogue avec la commande "find". Si tu cherches tous les fichiers commençant par "a", il te faut écrire find ... -name "a*" avec des quottes explicites pour que la commande récupère cette étoile et puisse s'en servir, elle, dans son action interne. C'est elle qui s'occupera de la mettre en regex pour ensuite comparer les fichiers trouvés avec le nom demandé "a*". Si tu ne protèges pas cette étoile par un outil de protection (quottes simples, doubles, backslash) alors le shell l'interceptera et la commande "find" ne la recevra pas (à noter que find ... -name 'a*' et find ... -name a\* fonctionnent aussi).
On a aussi la même chose avec l'option "-exec" du find. Quand on demande à find d'exécuter une commande, il faut indiquer où la commande se termine via un point-virgule. Mais pour que le find reçoive ce point-virgule (c'est un caractère spécial du shell donc si le shell le voit sans protection il le traite à sa manière) il faut aussi le protéger => find ... -name ... -exec ls -l {} \;.

La troisième est du même ordre. Il semble que la commande doive recevoir cette chaine "étoile" (ou ici "étoile/étoile") donc il faut protéger cette étoile du shell qui fait l'intermédiaire entre ce qu'il lit dans ton clavier et l'appel de la commande.

Tout se résume en "c'est quoi la différence entre echo *, echo \*, echo '*' et echo "*""...
PS: pour la première echo * il faut l'appeler dans un dossier non vide sinon ça affiche "étoile" à l'écran et on ne voit aucune différence avec les autres
21/10/2023, 18h14
Mr ZEE

Merci pour le topo de la commande "find"... (et pour ton post en entiers) :D

Il me semble que les deux premières sont des commandes qui contiennent deux commandes distinctes et indépendantes en une seule commande (je suis pas sur d'être clair ??).
Il y a une partie exécution de mise à jour et une partie d'écrasement de données. L'utilisation de l'étoile ne change rien.
Il n'y a manifestement pas de lien dans ces commandes pour exécuter dans le même temps la maj et le changement de données.
On demande en gros de mettre à jour le système et d'écraser le contenus du dossier /usr/lib/locale/ (pour pouvoir exécuter la maj).
Le système ne peut pas répondre : "écraser ok ! mais avec quoi ?" pour la première et "écraser quoi ?" pour la deuxième.
D'où la référence biblio, l'action et la cible bien déterminée (à savoir le contenu des dossiers de /usr/lib/locale/) de la troisième qui apparemment a fonctionné.

Je pensais qu'il y avait une mauvaise utilisation de l'étoile dans les deux premières commandes ou tout du moins une utilisation des plus hasardeuse de l'étoile.
30/10/2023, 19h57
papajoker

bonjour

existe une aide pour l'option overwrite

Citation:

--overwrite <glob>

Passe outre les vérifications de conflit de fichier et écrase les fichiers contradictoires. Si le paquetage qu'on est sur le point d'installer contient des fichiers déjà installés et de même nom que glob, cette option écrasera ces fichiers. L'option --overwrite n'autorise pas l'écrasement d'un répertoire par un fichier conflictuel ou par paquetage comportant un fichier ou un répertoire conflictuel. Il est possible de donner une liste de noms séparés par des virgules. Il est possible d'exclure des noms en les précédant d'un point d'exclamation. Les derniers noms cités sur la lignes ont priorité sur ceux qui précédent. Un point d'exclamation en tête ou un contre-oblique doit être "protégés" par un caractère d'échappement.

Citation:

un contre-oblique doit être "protégés" par un caractère d'échappement

la traduction fr peut porter à confusion ? reste la version originale

Citation:

A leading literal exclamation mark or backslash needs to be escaped.

Dans le cas du forum:
Pour des raisons de sécurité, on essaye de donner le minimum de fichiers pouvant être écrasés

Code:

--overwrite "/usr/lib/locale/*"

On limite car, on peut avoir parfois plusieurs conflits de fichiers sur différents paquets et pour un paquet ("locale/???" ici) on désire écraser mais, pour les autres non

Sinon, ici on permet de tout écraser sur notre système ...

Code:

--overwrite "*"

Note: si on installe un unique paquet le "*" alors ne s'applique qu'aux fichiers de ce paquets. Ce qui revient donc au même si on n'a plus que ce paquet (glibc-locales) dans ta mise jour.
Ou, si nous savons que tu n'as qu'un seul conflit (le cas ici), nous pouvons ne pas restreindre.

Citation:

Envoyé par Mr ZEE

Le système ne peut pas répondre : "écraser ok ! mais avec quoi ?" pour la première et "écraser quoi ?" pour la deuxième.

pacman est en erreur dès qu'il doit installer un fichier qui n'a pas été installé par lui. C'était ton erreur "conflit de fichier".
pacman avec cette option, va pouvoir écraser ces fichiers "étrangers" si ils sont dans le chemin passé par cette option.
C'est pour tous les paquets installés/ou mis à jour avec ta commande et, ces mauvais fichiers seront écrasés par le contenu d'un paquet de notre commande.

Dans ton cas particulier, le paquet "glibc-locales" est dans ta mise à jour , il est donc inutile de le saisir dans ta commande (puisqu'il fera déjà partie de la liste des paquets)
04/11/2023, 13h23
Mr ZEE
Merci pour ta réponse, j'ai quelques petites précisions à te demander tout de même.
En reprenant les commandes qui ont été données en réponse sur le topic du forum de Manjaro.fr

Commande 1 :
Code:

1 2 sudo pacman -Syu --overwrite /usr/lib/locale/*
Citation:

Envoyé par papajoker

Dans le cas du forum:
Pour des raisons de sécurité, on essaye de donner le minimum de fichiers pouvant être écrasés
On limite car, on peut avoir parfois plusieurs conflits de fichiers sur différents paquets et pour un paquet ("locale/???" ici) on désire écraser mais, pour les autres non

Je note donc que cette commande cible un unique paquet ? Et que cette commande n'a apparemment pas fonctionné.

Commande 2 :
Code:

1 2 sudo pacman -Syu --overwrite '*'
Citation:

Envoyé par papajoker

Sinon, ici on permet de tout écraser sur notre système ...
Note: si on installe un unique paquet le "*" alors ne s'applique qu'aux fichiers de ce paquets. Ce qui revient donc au même si on n'a plus que ce paquet (glibc-locales) dans ta mise jour.

Veux tu dire que l'utisation de '*' permet d'écraser tous paquets qui posent problème ?
Je note qu'il s'agissait d'une mise à jour importante concernant donc plusieurs paquets (130 en l'occurrence) et que cette commande n'a apparemment pas été utilisée.

Citation:

Envoyé par papajoker

Ou, si nous savons que tu n'as qu'un seul conflit (le cas ici), nous pouvons ne pas restreindre.

Je note qu'au post 5 du topic il est apparu un premier conflit de paquet (libgedit-amtk | amtk avant donc l'observation du conflit glibc-locales) qui a été résolu en acceptant la suppression de amtk pour libgedit-amtk. Comment est-on sûr alors qu'il n'y aura pas d'autres conflits en proposant --overwrite '*' pour, si je suis bien ton explication, "tout écraser sur notre système" ?

Citation:

Envoyé par papajoker

pacman est en erreur dès qu'il doit installer un fichier qui n'a pas été installé par lui.

Comment une mise à jour pacman peut elle réagir sur un paquet dont il n'est pas issu ?

Citation:

Envoyé par papajoker

Dans ton cas particulier, le paquet "glibc-locales" est dans ta mise à jour , il est donc inutile de le saisir dans ta commande (puisqu'il fera déjà partie de la liste des paquets)

Commande 3 :
Code:

1 2 sudo pacman -Syu glibc-locales --overwrite /usr/lib/locale/\*/\*
Je note que cette commande précise le paquet (glibc-locales), le chemin du répertoire (/usr/lib/locale/) et ce qu'il faut y écraser (\*/\*) ? Que cette commande a été utilisée et a apparemment fonctionné.
Qu'accessoirement cette commande était déjà documentée avant mention faite du conflit glibc-locales dans le topic du forum de Manjaro.fr ?

Citation:

Envoyé par Mr ZEE

Merci pour ta réponse, j'ai quelques petites précisions à te demander tout de même.

:oops: En fait tu n'as rien compris à mes explications (mea culpa)

Dans un premier temps, tu dois lire la doc : man et wiki

Tu confonds tout et mélange tout, il n'y a donc aucune chance que tu comprennes.

Citation:

Veux tu dire que l'utisation de '*' permet d'écraser tous paquets qui posent problème ?

Je note qu'au post 5 du topic il est apparu un premier conflit de paquet (libgedit-amtk | amtk avant donc l'observation du conflit glibc-locales) qui a été résolu en acceptant la suppression de amtk pour libgedit-amtk. Comment est-on sûr alors qu'il n'y aura pas d'autres conflits en proposant --overwrite '*' pour, si je suis bien ton explication, "tout écraser sur notre système" ?

Premier point important : conflit de paquets et conflit de fichiers sont 2 choses très différentes !
"amtk" était un conflit de paquets (des versions qui ne match pas) donc rien à voir avec un conflit de fichier et encore moins avec l'option "overwrite" qui n'est que pour fichiers.

Ton problème remonté était uniquement de conflit de fichier.

dans ton cas, indiquer le nom du paquet dans la commande ne change strictement rien (le paquet est dans la mise à jour)
Faire un "blog" strict ou plus global ne va rien changer à ton résultat (juste + sécure ou non)
Ne pas confondre une écriture du "blog" encadrée par des guillemets ou non

Le plus simple est sans doute de faire toi-même des essais ? Pour comprendre qu'il y a X façons d'écrire la même commande pour un même problème de fichier.

1) Créer un "fichier" qui va être en conflit avec un paquet (Le supprimer à la fin !)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 sudo mkdir /usr/share/licenses/ali sudo pacman -S ali résolution des dépendances… recherche des conflits entre paquets… :: Procéder à l’installation*? [O/n] :: Récupération des paquets… (1/1) vérification de l’intégrité des paquets [###############################################] 100% ... (1/1) analyse des conflits entre fichiers [###############################################] 100% erreur: la validation de la transaction a échoué (conflit de fichiers*) ali: /usr/share/licenses/ali est déjà présent dans le système de fichiers Des erreurs se sont produites, aucun paquet n’a été mis à jour.
Maintenant avec "/usr/share/licenses/ali" nous avons un conflit avec le paquet aliIl ne reste plus qu'à faire des tests pour comprendre par nous-mêmes
par exemple :
Code:

1 2 3 4 5 6 sudo pacman -S ali --overwrite "usr/share/licences/*" sudo pacman -S ali --overwrite "/usr/share/licences/*" sudo pacman -S ali --overwrite /usr/share/licences/* sudo pacman -S ali --overwrite usr/share/licences/\* sudo pacman -S ali --overwrite /usr/share/licences/\* sudo pacman -S ali --overwrite "/usr/share/*"
Si install est ok, alors supprimer le paquet puis recréer le méchant fichier sudo pacman -Rsn ali & sudo mkdir /usr/share/licenses/ali.
ps: dans tout ce lot, une seule commande ne passe pas (avec tes tests, tu vas trouver et pourquoi...), donc j'ai au moins 5 solutions pour écrire ma bonne commande (et je n'ai pas remonté toute l'arborescence)

-------------------------------

Citation:

Qu'accessoirement cette commande était déjà documentée avant mention faite du conflit glibc-locales dans le topic du forum de Manjaro.fr ?

L'annonce fr pointe toujours vers le second message du forum inter. Ce second message est de type "WIKI", il va référencer les principaux problèmes et les solutions. Puisque c'est un wiki, un problème/solution peut apparaitre après comme avant l'annonce de la mise à jour.