"Pour modifier la façon dont est cherché le PATH, ce n'est pas le shell qu'il faudrait modifier, mais les appels système exec*. C'est effectivement une révolution, et je ne pense pas que ce soit une bonne idée, ne serait-ce qu'à cause de la lenteur d'un tel système."
Ca ne serait pas forcement super lent. Il suffirait (comme suggeré plus haut) de garder une trace des différents repertoires de binaires existant, soit en mémoire (donc un premier accès a exec* plutot lent....), soit dans un fichier (mais rendre un appel systeme dependant d'un fichier de conf...brrrr....).
Une solution intermediaire est d'ecrire une couche d'encapsulation des exec*, mais la encore, qu'est-ce qui nous prouve que tout le monde va l'utiliser? (question rethorique, bien sur que PERSONNE ne l'utiliserait).
J'en profite, au passage, pour rappeler la méthode utilisée par l'envirronement graphique ROX: les applications directories. Chaque application "end user" (de préférence n'etant pas dependance d'une autre appli) est stockée dans un repertoire pour elle toute seule, avec un bin, un share (des equivalents en fait, les noms ne sont pas les memes). Un simple accès au repertoire de l'application execute/compile(si besoin) l'application. Il est a noter qu'un patch pour permettre a bash de gerer ces repertoires a été fourni.
Dans un autre ordre d'idées, il y avait une rumeur il y a quelques années d'un systeme de packages basé sur autoconf, avec l'énorme avantage de gérer ses dependances tout seul, et non sur un grosse base de donnée des softs installés; donc cohabitant parfaitement avec les softs installés "a la paluche". Quelqu'un a des nouvelles?
En melangeant toutes ces idées, on peut peut-etre arriver a une facon différente de gérer ses packages, personnelement j'experimente regulierement (mais ca marche tres mal, soyons honnetes).
[^] # Re: outils de packages
Posté par Olivier M. . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 10.
Ca ne serait pas forcement super lent. Il suffirait (comme suggeré plus haut) de garder une trace des différents repertoires de binaires existant, soit en mémoire (donc un premier accès a exec* plutot lent....), soit dans un fichier (mais rendre un appel systeme dependant d'un fichier de conf...brrrr....).
Une solution intermediaire est d'ecrire une couche d'encapsulation des exec*, mais la encore, qu'est-ce qui nous prouve que tout le monde va l'utiliser? (question rethorique, bien sur que PERSONNE ne l'utiliserait).
J'en profite, au passage, pour rappeler la méthode utilisée par l'envirronement graphique ROX: les applications directories. Chaque application "end user" (de préférence n'etant pas dependance d'une autre appli) est stockée dans un repertoire pour elle toute seule, avec un bin, un share (des equivalents en fait, les noms ne sont pas les memes). Un simple accès au repertoire de l'application execute/compile(si besoin) l'application. Il est a noter qu'un patch pour permettre a bash de gerer ces repertoires a été fourni.
Dans un autre ordre d'idées, il y avait une rumeur il y a quelques années d'un systeme de packages basé sur autoconf, avec l'énorme avantage de gérer ses dependances tout seul, et non sur un grosse base de donnée des softs installés; donc cohabitant parfaitement avec les softs installés "a la paluche". Quelqu'un a des nouvelles?
En melangeant toutes ces idées, on peut peut-etre arriver a une facon différente de gérer ses packages, personnelement j'experimente regulierement (mais ca marche tres mal, soyons honnetes).