Changer les permissions sur lot de fichiers .pkg

[berami]

Bonjour à tous,

J'ai un dossier qui contient une cinquantaine de fichiers "pkg" et souhaiterais changer les permissions de tous ces fichiers d'un seul coup
N'ayant aucun talent dans la formulation sous "terminal"...! quelqu'un pourrait-il m'aider?
J'aimerais savoir aussi s'il y a une solution pour que tous les sous fichiers des paquets "pkg" vont subir ce changement ou si c'est simplement l'enveloppe "pkg". (Je ne sais pas si je suis clair )
En fait j'aimerais qu'aucun fichier ne fasse obstruction à l'ouverture.
Bonne après midi à tous

 

[Membre supprimé 1060554]

Salut berami.

Je ne saisis pas explicitement l'intention de ton intention (si je puis dire), mais je remonte nonobstant ton fil, adorné d'une apostille d'écolier, en haut de la pile des messages du forum afin de le soumettre à l'attention du maître : bompi, lequel aura peut-être la bienveillance d'éclairer ta lanterne (après avoir eu la tâche ingrate d'ingérer mon indigeste tartine de prose matinale

...).

berami écrit: J'aimerais savoir aussi s'il y a une solution pour que tous les sous fichiers des paquets "pkg" vont subir ce changement ou si c'est simplement l'enveloppe "pkg".

Les .pkg sont des packages ("paquets" ou "paquetages" d'installation). On pourrait donc les croire assimilables à des dossiers classiques contenant de simples fichiers, si bien qu'une commande récursive (-R) de type chown ("change owner") et/ou chmod ("change mode") sur le package (ce que tu appelles : l'enveloppe) affecterait l'arborescence de son contenu de fichiers comme s'il s'agissait d'un banal dossier.

Néanmoins, j'entrevois 2 objections à cette perspective :

-a) Tout d'abord les.pkg (comme par exemple : ceux recelés dans l'installateur de «Yosemite» at: Install\ OS\ X\ Yosemite.app/Contents/SharedSupport/InstallESD.dmg --> /Volumes/OS\ X\ Install\ ESD/packages que tu peux télécharger depuis l'AppStore) ont la nature de : flattened packages ("paquets aplatis") qui confère à leur structure de dossiers une configuration de fichiers --> cette caractéristique interdit à une commande récursive sur un flattened package de concerner la profondeur de son arborescence de fichiers comme s'il s'agissait d'un dossier ordinaire.

Tu peux t'en assurer sur un exemple : suppose que je sélectionne dans les packages de l'installateur de «Yosemite» le Essentials.pkg (qui, en qualité de flattened package, a donc l'allure d'un fichier) et que je lui applique dans le «Terminal» une commande récursive de changement d'accédants (user + group) du type :

sudo chown -R toto:staff /path_to_file/Essentials.pkg

(où toto est un admin réel de mon OS quoique "bidon", càd. n'existant qu'à fins d'expérimentations) --> je vais donc me demander si cette commande récursive a ou non affecté la profondeur de l'arborescence de fichiers de mon flattened package : Essentials.pkg et comment m'en assurer? Pour cela, il va me suffire de "désaplatir" mon flattened package afin de lui restituer la forme classique d'un dossier par la commande :

sudo pkgutil --expand /path_to_file/Essentials.pkg ~/Desktop/Essentials

et le contenu de fichiers de mon flattened package : Essentials.pkg va se retrouver "expansé" dans un dossier Essentials créé ad hoc sur mon Bureau --> je vais pouvoir contempler l'arborescence y contenue, à savoir : un fichier Bom ("Bill of Materials"), un fichier PackageInfo, un fichier archive Payload (recelant la "cargaison") et enfin un dossier Scripts contenant lui-même une arborescence complexe d'exécutables : binaires et scripts shell) --> si je m'informe à présent (par un simple ⌘I sur tel ou tel élément contenu dans mon dossier d'expansion du flattened package : Essentials.pkg) de ce qu'il en est des accédants - eh bien! le résultat est sans appel : j'obtiens root:wheel ("Super-User" + "Groupe-Système") dans tous les cas de figures --> ma commande récursive chown n'a donc en rien affecté l'arborescence du flattened package : Essentials.pkg, elle n'a modifié que les accédants au niveau de l'enveloppe - comme tu dis.

♤​

-b) ensuite et plus fondamentalement, je me figure (en mode : simple raisonnement de bon sens) que si root:wheel (et pas toto:staff) sont les accédants par défaut du .pkg dans toute la profondeur de son arborescence, c'est pour que les fichiers installés dans le domaine-Système soient a priori possédés par l'Utilisateur-Système justement (tandis que ceux qui peuvent s'installer dans le Dossier de Compte de l'utilisateur seront, eux, possédés par de dernier).

Il s'ensuit que dans le fichier "cargaison" Payload (où se trouvent archivés tous les composants à installer), chaque composant de cette archive se trouve affecté par défaut du droit de propriété : root:wheel sans qu'aucune manipulation de l'archive résultante ne puisse rien y changer.

Quelqu'un qui voudrait changer la donne en termes d'accédants dans toute la profondeur de l'arborescence du fichier "cargaison" Payload, devrait - je me figure - carrément reconstruire le .pkg en utilisant un programme comme pkgbuid avec une option --ownership spécifique - ce qui reviendrait à une re-création de l'archive depuis les fondations, et pas une modification des accédants appliquée de l'extérieur à une cargaison achevée.

♧
​

☞ comme je ne suis en aucune forme, figure ni mode un développeur, mais un simple animal rationale

tentant d'appliquer le bon sens naturel au domaine informatique - je ne peux en dire plus sur le caractère manipulable a posteriori des .pkg - chose dont je m'abstiens soigneusement comme se trouvant hors de mon domaine d'expertise.

♡​

 

[berami]

bonjour macomaniac
Merci pour ta réponse plus que détaillée.
je n'ai pas trop de temps mais je vais relire cela