Bonjour,
J'ai fais une bêtise et je ne vois pas comment la réparer. Si vous pouviez
m'aider...
J'ai Aurox 9.3. C'est une base RedHat.
Pour activer et désactiver le réseau, il me faut appeler
/usr/bin/redhat-config-network qui est un lien symbolique vers
consolehelper et donner le mot de passe de su.
Je suis seul à utiliser ma machine donc, pour me débarrasser du mot de
passe, j'ai fait
chmod +s redhat-config-network
Avec ls -l, aucun s dans les autorisations de ce lien. En revanche, le s est
(apparaît ???) pour consolehelper.
un ls-l redhat-config* m'affiche en rouge tous les liens symboliques vers
consolehelper donc anomalie :
[normal@localhost bin]$ ls -l redhat-con*
lrwxrwxrwx 1 root root 13 avr 18 13:41
redhat-config-authentication -> consolehelper
lrwxrwxrwx 1 root root 13 avr 18 13:41 redhat-config-date
-> consolehelper
etc pour la floppée de liens symboliques.
Je n'ai plus accès à consolhelper depuis KDE en mode utilisateur.
[root@localhost bin]# ls -l consolehelper
-r-sr-sr-x 1 root root 5288 avr 20 17:38 consolehelper
Ici encore, consolehelper apparaît en rouge, donc problème ! J'ai essayé de
remettre les autorisations d'avant :
chmod +x redhat-config-network
ou
chmod +x consolhelper, rien n'y fait.
Alors, si vous aviez une solution, je vous en serais bien reconnaissant.
Bonne soirée,
Dominique
Dans le message <news:cdbi2k$bi3$, *Dominique* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
J'ai fais une bêtise et je ne vois pas comment la réparer. Si vous pouviez m'aider... J'ai Aurox 9.3. C'est une base RedHat. Pour activer et désactiver le réseau, il me faut appeler /usr/bin/redhat-config-network qui est un lien symbolique vers consolehelper et donner le mot de passe de su. Je suis seul à utiliser ma machine donc, pour me débarrasser du mot de passe, j'ai fait chmod +s redhat-config-network Avec ls -l, aucun s dans les autorisations de ce lien.
Normal. Les permissions sur un lien symbolique n'ont aucun effet.
En revanche, le s est (apparaît ???) pour consolehelper.
Normal et logique, non ?
un ls-l redhat-config* m'affiche en rouge tous les liens symboliques vers consolehelper donc anomalie :
Pourquoi anomalie ? Les couleurs affichées par la commande 'ls' ne font qu'indiquer un type de fichier (device, fifo, fichier, répertoire, ...), l'état d'un fichier (exécutable, orphelin, setuid, ...) ou la catégorie des fichiers (archives, images, vidéos, ...). La couleur rouge signifie généralement que le fichier est setuid. Le choix de cette couleur est judicieux car il permet de repérer et de distinguer rapidement les fichiers exécutables normaux des fichiers exécutables setuid. De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Oui, des liens symboliques avec les classiques permissions dessus. Rien de plus.
Je n'ai plus accès à consolhelper depuis KDE en mode utilisateur.
Certainement du à une protection au niveau de KDE ou au niveau de la commande consolhelper qui empêche l'exécution de ce programme s'il est setuid. Mais il aurait été intéressant que vous nous disiez exactement ce qui se passe quand vous tentez de lancer ce programme. Message d'erreur ? Log ?
[ bin]# ls -l consolehelper -r-sr-sr-x 1 root root 5288 avr 20 17:38 consolehelper Ici encore, consolehelper apparaît en rouge, donc problème !
Non, pas de problème ! Vous voyez un problème sur le fichier ? Bref, il est affiché en rouge car il est effectivement setuid.
J'ai essayé de remettre les autorisations d'avant : chmod +x redhat-config-network ou chmod +x consolhelper, rien n'y fait.
La logique voudrait que vous fassiez la commande inverse de celle que vous aviez tapez précédemment... +s devenant -s, logique, non ? :) Donc :
$ chmod -s redhat-config-network
ou plutôt directement :
$ chmod -s consolhelper
Ou encore :
$ chmod 755 consolhelper
Une lecture des deux sites suivant vous aidera à mieux maîtriser la gestion des permissions :
Alors, si vous aviez une solution, je vous en serais bien reconnaissant.
Une explication sur votre problème qui n'en était pas un, c'est fait. Une solution pour remettre les bonnes permissions sur votre commande, c'est fait aussi. Une solution pour lancer votre commande sans saisir de mot de passe serait d'utiliser sudo. Mais bon, la question que je me pose c'est pourquoi vouloir activer et désactiver le réseau ? Cela cacherait-il un autre problème qui alors serait plus judicieux de résoudre que de vouloir s'en sortir par un tour de passe-passe ?
Bonne soirée,
Vous de même.
-- TiChou
Dans le message <news:cdbi2k$bi3$1@news-reader4.wanadoo.fr>,
*Dominique* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
J'ai fais une bêtise et je ne vois pas comment la réparer. Si vous pouviez
m'aider...
J'ai Aurox 9.3. C'est une base RedHat.
Pour activer et désactiver le réseau, il me faut appeler
/usr/bin/redhat-config-network qui est un lien symbolique vers
consolehelper et donner le mot de passe de su.
Je suis seul à utiliser ma machine donc, pour me débarrasser du mot de
passe, j'ai fait
chmod +s redhat-config-network
Avec ls -l, aucun s dans les autorisations de ce lien.
Normal. Les permissions sur un lien symbolique n'ont aucun effet.
En revanche, le s est (apparaît ???) pour consolehelper.
Normal et logique, non ?
un ls-l redhat-config* m'affiche en rouge tous les liens symboliques vers
consolehelper donc anomalie :
Pourquoi anomalie ? Les couleurs affichées par la commande 'ls' ne font
qu'indiquer un type de fichier (device, fifo, fichier, répertoire, ...),
l'état d'un fichier (exécutable, orphelin, setuid, ...) ou la catégorie des
fichiers (archives, images, vidéos, ...).
La couleur rouge signifie généralement que le fichier est setuid. Le choix
de cette couleur est judicieux car il permet de repérer et de distinguer
rapidement les fichiers exécutables normaux des fichiers exécutables setuid.
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de
la même couleur que leur fichier source.
Oui, des liens symboliques avec les classiques permissions dessus. Rien de
plus.
Je n'ai plus accès à consolhelper depuis KDE en mode utilisateur.
Certainement du à une protection au niveau de KDE ou au niveau de la
commande consolhelper qui empêche l'exécution de ce programme s'il est
setuid.
Mais il aurait été intéressant que vous nous disiez exactement ce qui se
passe quand vous tentez de lancer ce programme. Message d'erreur ? Log ?
[root@localhost bin]# ls -l consolehelper
-r-sr-sr-x 1 root root 5288 avr 20 17:38 consolehelper
Ici encore, consolehelper apparaît en rouge, donc problème !
Non, pas de problème ! Vous voyez un problème sur le fichier ?
Bref, il est affiché en rouge car il est effectivement setuid.
J'ai essayé de remettre les autorisations d'avant :
chmod +x redhat-config-network
ou
chmod +x consolhelper, rien n'y fait.
La logique voudrait que vous fassiez la commande inverse de celle que vous
aviez tapez précédemment... +s devenant -s, logique, non ? :)
Donc :
$ chmod -s redhat-config-network
ou plutôt directement :
$ chmod -s consolhelper
Ou encore :
$ chmod 755 consolhelper
Une lecture des deux sites suivant vous aidera à mieux maîtriser la gestion
des permissions :
Alors, si vous aviez une solution, je vous en serais bien reconnaissant.
Une explication sur votre problème qui n'en était pas un, c'est fait.
Une solution pour remettre les bonnes permissions sur votre commande, c'est
fait aussi.
Une solution pour lancer votre commande sans saisir de mot de passe serait
d'utiliser sudo.
Mais bon, la question que je me pose c'est pourquoi vouloir activer et
désactiver le réseau ? Cela cacherait-il un autre problème qui alors serait
plus judicieux de résoudre que de vouloir s'en sortir par un tour de
passe-passe ?
Dans le message <news:cdbi2k$bi3$, *Dominique* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
J'ai fais une bêtise et je ne vois pas comment la réparer. Si vous pouviez m'aider... J'ai Aurox 9.3. C'est une base RedHat. Pour activer et désactiver le réseau, il me faut appeler /usr/bin/redhat-config-network qui est un lien symbolique vers consolehelper et donner le mot de passe de su. Je suis seul à utiliser ma machine donc, pour me débarrasser du mot de passe, j'ai fait chmod +s redhat-config-network Avec ls -l, aucun s dans les autorisations de ce lien.
Normal. Les permissions sur un lien symbolique n'ont aucun effet.
En revanche, le s est (apparaît ???) pour consolehelper.
Normal et logique, non ?
un ls-l redhat-config* m'affiche en rouge tous les liens symboliques vers consolehelper donc anomalie :
Pourquoi anomalie ? Les couleurs affichées par la commande 'ls' ne font qu'indiquer un type de fichier (device, fifo, fichier, répertoire, ...), l'état d'un fichier (exécutable, orphelin, setuid, ...) ou la catégorie des fichiers (archives, images, vidéos, ...). La couleur rouge signifie généralement que le fichier est setuid. Le choix de cette couleur est judicieux car il permet de repérer et de distinguer rapidement les fichiers exécutables normaux des fichiers exécutables setuid. De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Oui, des liens symboliques avec les classiques permissions dessus. Rien de plus.
Je n'ai plus accès à consolhelper depuis KDE en mode utilisateur.
Certainement du à une protection au niveau de KDE ou au niveau de la commande consolhelper qui empêche l'exécution de ce programme s'il est setuid. Mais il aurait été intéressant que vous nous disiez exactement ce qui se passe quand vous tentez de lancer ce programme. Message d'erreur ? Log ?
[ bin]# ls -l consolehelper -r-sr-sr-x 1 root root 5288 avr 20 17:38 consolehelper Ici encore, consolehelper apparaît en rouge, donc problème !
Non, pas de problème ! Vous voyez un problème sur le fichier ? Bref, il est affiché en rouge car il est effectivement setuid.
J'ai essayé de remettre les autorisations d'avant : chmod +x redhat-config-network ou chmod +x consolhelper, rien n'y fait.
La logique voudrait que vous fassiez la commande inverse de celle que vous aviez tapez précédemment... +s devenant -s, logique, non ? :) Donc :
$ chmod -s redhat-config-network
ou plutôt directement :
$ chmod -s consolhelper
Ou encore :
$ chmod 755 consolhelper
Une lecture des deux sites suivant vous aidera à mieux maîtriser la gestion des permissions :
Alors, si vous aviez une solution, je vous en serais bien reconnaissant.
Une explication sur votre problème qui n'en était pas un, c'est fait. Une solution pour remettre les bonnes permissions sur votre commande, c'est fait aussi. Une solution pour lancer votre commande sans saisir de mot de passe serait d'utiliser sudo. Mais bon, la question que je me pose c'est pourquoi vouloir activer et désactiver le réseau ? Cela cacherait-il un autre problème qui alors serait plus judicieux de résoudre que de vouloir s'en sortir par un tour de passe-passe ?
Bonne soirée,
Vous de même.
-- TiChou
Ronald
Salut,
Le Sat, 17 Jul 2004 20:13:23 +0200, TiChou a écrit :
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une distribution spécifique, mais ça dépend plutôt de ce que tu as dans ton ~/.dir_colors (LINK)
Salut,
Le Sat, 17 Jul 2004 20:13:23 +0200, TiChou a écrit :
De plus,
il faut noter que la commande 'ls' affiche les liens symboliques de la
même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une
distribution spécifique, mais ça dépend plutôt de ce que tu as dans
ton ~/.dir_colors (LINK)
Le Sat, 17 Jul 2004 20:13:23 +0200, TiChou a écrit :
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une distribution spécifique, mais ça dépend plutôt de ce que tu as dans ton ~/.dir_colors (LINK)
TiChou
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Salut,
Bonsoir,
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une distribution spécifique, mais ça dépend plutôt de ce que tu as dans ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les coreutils, le comportement est bien celui que j'ai décrit. S'il est différent, c'est que la distribution utilise un fichier /etc/DIR_COLORS qui lui est propre et donc différent ou que dans votre fichier ~/.dir_colors vous avez décidé d'utiliser une coloration différente de celle par défaut.
-- TiChou
Dans le message <news:pan.2004.07.17.18.27.17.770689@reply.to>,
*Ronald* tapota sur f.c.o.l.configuration :
Salut,
Bonsoir,
De plus,
il faut noter que la commande 'ls' affiche les liens symboliques de la
même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une
distribution spécifique, mais ça dépend plutôt de ce que tu as dans
ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les coreutils,
le comportement est bien celui que j'ai décrit. S'il est différent, c'est
que la distribution utilise un fichier /etc/DIR_COLORS qui lui est propre et
donc différent ou que dans votre fichier ~/.dir_colors vous avez décidé
d'utiliser une coloration différente de celle par défaut.
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Salut,
Bonsoir,
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une distribution spécifique, mais ça dépend plutôt de ce que tu as dans ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les coreutils, le comportement est bien celui que j'ai décrit. S'il est différent, c'est que la distribution utilise un fichier /etc/DIR_COLORS qui lui est propre et donc différent ou que dans votre fichier ~/.dir_colors vous avez décidé d'utiliser une coloration différente de celle par défaut.
-- TiChou
Ronald
Le Sat, 17 Jul 2004 21:31:30 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Salut,
Bonsoir,
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une distribution spécifique, mais ça dépend plutôt de ce que tu as dans ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les coreutils, le comportement est bien celui que j'ai décrit. S'il est différent, c'est que la distribution utilise un fichier /etc/DIR_COLORS qui lui est propre et donc différent ou que dans votre fichier ~/.dir_colors vous avez décidé d'utiliser une coloration différente de celle par défaut.
Pas nécessairement: _sans_ /etc/DIR_COLORS eval 'dircolors` ou tout simplement dircolors les couleurs par défaut sont définie dans le code apparemment. ok, c'est juste pinailler ;)
Le Sat, 17 Jul 2004 21:31:30 +0200, TiChou a écrit :
Dans le message <news:pan.2004.07.17.18.27.17.770689@reply.to>, *Ronald*
tapota sur f.c.o.l.configuration :
Salut,
Bonsoir,
De plus,
il faut noter que la commande 'ls' affiche les liens symboliques de la
même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une
distribution spécifique, mais ça dépend plutôt de ce que tu as dans
ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les
coreutils, le comportement est bien celui que j'ai décrit. S'il est
différent, c'est que la distribution utilise un fichier /etc/DIR_COLORS
qui lui est propre et donc différent ou que dans votre fichier
~/.dir_colors vous avez décidé d'utiliser une coloration différente de
celle par défaut.
Pas nécessairement:
_sans_ /etc/DIR_COLORS
eval 'dircolors` ou tout simplement dircolors
les couleurs par défaut sont définie dans le code apparemment.
ok, c'est juste pinailler ;)
Le Sat, 17 Jul 2004 21:31:30 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Salut,
Bonsoir,
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une distribution spécifique, mais ça dépend plutôt de ce que tu as dans ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les coreutils, le comportement est bien celui que j'ai décrit. S'il est différent, c'est que la distribution utilise un fichier /etc/DIR_COLORS qui lui est propre et donc différent ou que dans votre fichier ~/.dir_colors vous avez décidé d'utiliser une coloration différente de celle par défaut.
Pas nécessairement: _sans_ /etc/DIR_COLORS eval 'dircolors` ou tout simplement dircolors les couleurs par défaut sont définie dans le code apparemment. ok, c'est juste pinailler ;)
TiChou
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une distribution spécifique, mais ça dépend plutôt de ce que tu as dans ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les coreutils, le comportement est bien celui que j'ai décrit. S'il est différent, c'est que la distribution utilise un fichier /etc/DIR_COLORS qui lui est propre et donc différent ou que dans votre fichier ~/.dir_colors vous avez décidé d'utiliser une coloration différente de celle par défaut.
Pas nécessairement: _sans_ /etc/DIR_COLORS eval 'dircolors` ou tout simplement dircolors les couleurs par défaut sont définie dans le code apparemment.
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le comportement que j'ai décris.
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la ou les distributions, parmi les distributions les plus courantes, qui n'auraient pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut être aussi /etc/dircolors) et qui, dans le profile par défaut du shell, n'exporteraient pas la variable LS_COLORS avec la commande dircolors ? ;-) Et dites moi alors l'intérêt d'utiliser l'option color de la commande 'ls' si quasi aucunes couleurs n'est définies ? ;-)
-- TiChou
Dans le message <news:pan.2004.07.17.19.44.55.757741@reply.to>,
*Ronald* tapota sur f.c.o.l.configuration :
il faut noter que la commande 'ls' affiche les liens symboliques de la
même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une
distribution spécifique, mais ça dépend plutôt de ce que tu as dans
ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les
coreutils, le comportement est bien celui que j'ai décrit. S'il est
différent, c'est que la distribution utilise un fichier /etc/DIR_COLORS
qui lui est propre et donc différent ou que dans votre fichier
~/.dir_colors vous avez décidé d'utiliser une coloration différente de
celle par défaut.
Pas nécessairement:
_sans_ /etc/DIR_COLORS
eval 'dircolors` ou tout simplement dircolors
les couleurs par défaut sont définie dans le code apparemment.
Je ne suis pas certain d'avoir tout compris.
Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut
le comportement que j'ai décris.
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la ou les
distributions, parmi les distributions les plus courantes, qui n'auraient
pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut être aussi
/etc/dircolors) et qui, dans le profile par défaut du shell, n'exporteraient
pas la variable LS_COLORS avec la commande dircolors ? ;-)
Et dites moi alors l'intérêt d'utiliser l'option color de la commande 'ls'
si quasi aucunes couleurs n'est définies ? ;-)
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
Désolé de te contrarier, tu évoques peut être le cas d'une distribution spécifique, mais ça dépend plutôt de ce que tu as dans ton ~/.dir_colors (LINK)
Et par défaut, avec le fichier /etc/DIR_COLORS fournit dans les coreutils, le comportement est bien celui que j'ai décrit. S'il est différent, c'est que la distribution utilise un fichier /etc/DIR_COLORS qui lui est propre et donc différent ou que dans votre fichier ~/.dir_colors vous avez décidé d'utiliser une coloration différente de celle par défaut.
Pas nécessairement: _sans_ /etc/DIR_COLORS eval 'dircolors` ou tout simplement dircolors les couleurs par défaut sont définie dans le code apparemment.
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le comportement que j'ai décris.
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la ou les distributions, parmi les distributions les plus courantes, qui n'auraient pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut être aussi /etc/dircolors) et qui, dans le profile par défaut du shell, n'exporteraient pas la variable LS_COLORS avec la commande dircolors ? ;-) Et dites moi alors l'intérêt d'utiliser l'option color de la commande 'ls' si quasi aucunes couleurs n'est définies ? ;-)
-- TiChou
Ronald
Le Sat, 17 Jul 2004 22:07:41 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le comportement que j'ai décris.
Non, DIR_COLORS est déjà un fichier de config dans lequel tu vas définir les couleurs, écrasant par là même la config qui est codée en dur.
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la ou les distributions, parmi les distributions les plus courantes, qui n'auraient pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut être aussi /etc/dircolors) et qui, dans le profile par défaut du shell, n'exporteraient pas la variable LS_COLORS avec la commande dircolors ? ;-) Et dites moi alors l'intérêt d'utiliser l'option color de la commande 'ls' si quasi aucunes couleurs n'est définies ? ;-)
1) Pour les distros, je n'en sais rien à vrai dire, ça fait un petit moment que je n'en utilise plus. 2) regardes la sortie d'un simple dircolors, la dernière ligne exporte bien LS_COLORS, pas même besoin d'un fichier de conf. 3) quelques couleurs sont définies, quand bien même ta variable LS_COLORS serait vide.
Le Sat, 17 Jul 2004 22:07:41 +0200, TiChou a écrit :
Dans le message <news:pan.2004.07.17.19.44.55.757741@reply.to>, *Ronald*
tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS
ou eval `dircolors` définissent bien par défaut le comportement que j'ai
décris.
Non, DIR_COLORS est déjà un fichier de config dans lequel tu vas
définir les couleurs, écrasant par là même la config qui est codée en
dur.
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la
ou les distributions, parmi les distributions les plus courantes, qui
n'auraient pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut
être aussi /etc/dircolors) et qui, dans le profile par défaut du
shell, n'exporteraient pas la variable LS_COLORS avec la commande
dircolors ? ;-) Et dites moi alors l'intérêt d'utiliser l'option color
de la commande 'ls' si quasi aucunes couleurs n'est définies ? ;-)
1) Pour les distros, je n'en sais rien à vrai dire, ça fait un petit
moment que je n'en utilise plus.
2) regardes la sortie d'un simple dircolors, la dernière ligne exporte
bien LS_COLORS, pas même besoin d'un fichier de conf.
3) quelques couleurs sont définies, quand bien même ta variable
LS_COLORS serait vide.
Le Sat, 17 Jul 2004 22:07:41 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le comportement que j'ai décris.
Non, DIR_COLORS est déjà un fichier de config dans lequel tu vas définir les couleurs, écrasant par là même la config qui est codée en dur.
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la ou les distributions, parmi les distributions les plus courantes, qui n'auraient pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut être aussi /etc/dircolors) et qui, dans le profile par défaut du shell, n'exporteraient pas la variable LS_COLORS avec la commande dircolors ? ;-) Et dites moi alors l'intérêt d'utiliser l'option color de la commande 'ls' si quasi aucunes couleurs n'est définies ? ;-)
1) Pour les distros, je n'en sais rien à vrai dire, ça fait un petit moment que je n'en utilise plus. 2) regardes la sortie d'un simple dircolors, la dernière ligne exporte bien LS_COLORS, pas même besoin d'un fichier de conf. 3) quelques couleurs sont définies, quand bien même ta variable LS_COLORS serait vide.
TiChou
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le comportement que j'ai décris.
Non,
Quoi non ? Désolé, mais pas saisis où était votre désaccord.
DIR_COLORS est déjà un fichier de config dans lequel tu vas définir les couleurs,
Oui et je maintiens en disant que ce fichier ou que la commande dircolors sans préciser de fichier définissent bien par défaut le comportement que j'ai décrit pour les liens symboliques.
écrasant par là même la config qui est codée en dur.
Comme tout fichier de configuration, non ? :)
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la ou les distributions, parmi les distributions les plus courantes, qui n'auraient pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut être aussi /etc/dircolors) et qui, dans le profile par défaut du shell, n'exporteraient pas la variable LS_COLORS avec la commande dircolors ? ;-) Et dites moi alors l'intérêt d'utiliser l'option color de la commande 'ls' si quasi aucunes couleurs n'est définies ? ;-)
1) Pour les distros, je n'en sais rien à vrai dire, ça fait un petit moment que je n'en utilise plus.
Ben je crois que je peux m'avancer en disant aucune. ;)
2) regardes la sortie d'un simple dircolors, la dernière ligne exporte bien LS_COLORS,
La commande dircolors seul ne fait rien, c'est une commande passive qui se contente d'afficher la séquence de commandes à saisir ou à évaluer pour définir la variable LS_COLORS avec des options par défaut comme l'option du comportement que j'ai décrit ainsi que la définition de quelques couleurs. De même quand cette commande est lancé avec comme paramètre le fichier /etc/DIR_COLORS avec pour différence les options supplémentaires définies dans ce fichier.
Mais je n'ai pas compris pourquoi vous me parliez de cette commande et de l'exportation de la variable LS_COLORS.
pas même besoin d'un fichier de conf.
Pour ? J'ai du mal à suivre votre raisonnement.
3) quelques couleurs sont définies, quand bien même ta variable LS_COLORS serait vide.
Oui, 4 ou 5. C'est très maigre je trouve.
-- TiChou
Dans le message <news:pan.2004.07.17.20.23.33.286204@reply.to>,
*Ronald* tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS
ou eval `dircolors` définissent bien par défaut le comportement que j'ai
décris.
Non,
Quoi non ? Désolé, mais pas saisis où était votre désaccord.
DIR_COLORS est déjà un fichier de config dans lequel tu vas définir les
couleurs,
Oui et je maintiens en disant que ce fichier ou que la commande dircolors
sans préciser de fichier définissent bien par défaut le comportement que
j'ai décrit pour les liens symboliques.
écrasant par là même la config qui est codée en dur.
Comme tout fichier de configuration, non ? :)
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la
ou les distributions, parmi les distributions les plus courantes, qui
n'auraient pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut
être aussi /etc/dircolors) et qui, dans le profile par défaut du
shell, n'exporteraient pas la variable LS_COLORS avec la commande
dircolors ? ;-) Et dites moi alors l'intérêt d'utiliser l'option color
de la commande 'ls' si quasi aucunes couleurs n'est définies ? ;-)
1) Pour les distros, je n'en sais rien à vrai dire, ça fait un petit
moment que je n'en utilise plus.
Ben je crois que je peux m'avancer en disant aucune. ;)
2) regardes la sortie d'un simple dircolors, la dernière ligne exporte
bien LS_COLORS,
La commande dircolors seul ne fait rien, c'est une commande passive qui se
contente d'afficher la séquence de commandes à saisir ou à évaluer pour
définir la variable LS_COLORS avec des options par défaut comme l'option du
comportement que j'ai décrit ainsi que la définition de quelques couleurs.
De même quand cette commande est lancé avec comme paramètre le fichier
/etc/DIR_COLORS avec pour différence les options supplémentaires définies
dans ce fichier.
Mais je n'ai pas compris pourquoi vous me parliez de cette commande et de
l'exportation de la variable LS_COLORS.
pas même besoin d'un fichier de conf.
Pour ? J'ai du mal à suivre votre raisonnement.
3) quelques couleurs sont définies, quand bien même ta variable
LS_COLORS serait vide.
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le comportement que j'ai décris.
Non,
Quoi non ? Désolé, mais pas saisis où était votre désaccord.
DIR_COLORS est déjà un fichier de config dans lequel tu vas définir les couleurs,
Oui et je maintiens en disant que ce fichier ou que la commande dircolors sans préciser de fichier définissent bien par défaut le comportement que j'ai décrit pour les liens symboliques.
écrasant par là même la config qui est codée en dur.
Comme tout fichier de configuration, non ? :)
ok, c'est juste pinailler ;)
Peut être pas et la remarque à son intérêt. Mais alors dites moi la ou les distributions, parmi les distributions les plus courantes, qui n'auraient pas de fichier /etc/DIR_COLORS (ou son équivalent, ça peut être aussi /etc/dircolors) et qui, dans le profile par défaut du shell, n'exporteraient pas la variable LS_COLORS avec la commande dircolors ? ;-) Et dites moi alors l'intérêt d'utiliser l'option color de la commande 'ls' si quasi aucunes couleurs n'est définies ? ;-)
1) Pour les distros, je n'en sais rien à vrai dire, ça fait un petit moment que je n'en utilise plus.
Ben je crois que je peux m'avancer en disant aucune. ;)
2) regardes la sortie d'un simple dircolors, la dernière ligne exporte bien LS_COLORS,
La commande dircolors seul ne fait rien, c'est une commande passive qui se contente d'afficher la séquence de commandes à saisir ou à évaluer pour définir la variable LS_COLORS avec des options par défaut comme l'option du comportement que j'ai décrit ainsi que la définition de quelques couleurs. De même quand cette commande est lancé avec comme paramètre le fichier /etc/DIR_COLORS avec pour différence les options supplémentaires définies dans ce fichier.
Mais je n'ai pas compris pourquoi vous me parliez de cette commande et de l'exportation de la variable LS_COLORS.
pas même besoin d'un fichier de conf.
Pour ? J'ai du mal à suivre votre raisonnement.
3) quelques couleurs sont définies, quand bien même ta variable LS_COLORS serait vide.
Oui, 4 ou 5. C'est très maigre je trouve.
-- TiChou
Ronald
Le Sat, 17 Jul 2004 22:57:49 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le comportement que j'ai décris.
Non,
Quoi non ? Désolé, mais pas saisis où était votre désaccord.
DIR_COLORS est déjà un fichier de config dans lequel tu vas définir les couleurs,
Oui et je maintiens en disant que ce fichier ou que la commande dircolors sans préciser de fichier définissent bien par défaut le comportement que j'ai décrit pour les liens symboliques. [...]
Plus court: vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval `dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis moi: les liens sont ils de la même couleur que les executables vers lesquels ils pointent?
Le Sat, 17 Jul 2004 22:57:49 +0200, TiChou a écrit :
Dans le message <news:pan.2004.07.17.20.23.33.286204@reply.to>, *Ronald*
tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut,
/etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le
comportement que j'ai décris.
Non,
Quoi non ? Désolé, mais pas saisis où était votre désaccord.
DIR_COLORS est déjà un fichier de config dans lequel tu vas définir
les couleurs,
Oui et je maintiens en disant que ce fichier ou que la commande dircolors
sans préciser de fichier définissent bien par défaut le comportement
que j'ai décrit pour les liens symboliques.
[...]
Plus court:
vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval
`dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis
moi: les liens sont ils de la même couleur que les executables vers
lesquels ils pointent?
Le Sat, 17 Jul 2004 22:57:49 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Je ne suis pas certain d'avoir tout compris. Par défaut, /etc/DIR_COLORS ou eval `dircolors` définissent bien par défaut le comportement que j'ai décris.
Non,
Quoi non ? Désolé, mais pas saisis où était votre désaccord.
DIR_COLORS est déjà un fichier de config dans lequel tu vas définir les couleurs,
Oui et je maintiens en disant que ce fichier ou que la commande dircolors sans préciser de fichier définissent bien par défaut le comportement que j'ai décrit pour les liens symboliques. [...]
Plus court: vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval `dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis moi: les liens sont ils de la même couleur que les executables vers lesquels ils pointent?
TiChou
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
[...]
Plus court: vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval `dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis moi: les liens sont ils de la même couleur que les executables vers lesquels ils pointent?
Pour la nième fois, oui ! :)
Petit screenshot à l'appui :
http://magnolia.tichou.org/~tichou/dircolors.png
-- TiChou
Dans le message <news:pan.2004.07.17.21.15.40.882184@reply.to>,
*Ronald* tapota sur f.c.o.l.configuration :
[...]
Plus court:
vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval
`dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis
moi: les liens sont ils de la même couleur que les executables vers
lesquels ils pointent?
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
[...]
Plus court: vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval `dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis moi: les liens sont ils de la même couleur que les executables vers lesquels ils pointent?
Pour la nième fois, oui ! :)
Petit screenshot à l'appui :
http://magnolia.tichou.org/~tichou/dircolors.png
-- TiChou
Ronald
Le Sat, 17 Jul 2004 23:37:52 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
[...]
Plus court: vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval `dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis moi: les liens sont ils de la même couleur que les executables vers lesquels ils pointent?
Pour la nième fois, oui ! :)
Petit screenshot à l'appui :
http://magnolia.tichou.org/~tichou/dircolors.png
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Le Sat, 17 Jul 2004 23:37:52 +0200, TiChou a écrit :
Dans le message <news:pan.2004.07.17.21.15.40.882184@reply.to>, *Ronald*
tapota sur f.c.o.l.configuration :
[...]
Plus court:
vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval
`dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis
moi: les liens sont ils de la même couleur que les executables vers
lesquels ils pointent?
Pour la nième fois, oui ! :)
Petit screenshot à l'appui :
http://magnolia.tichou.org/~tichou/dircolors.png
Moi je vois pwet en cyan qui pointe vers ping en gris surligné
en rouge, il faut peut être que je consulte un oculiste, alors?
Le Sat, 17 Jul 2004 23:37:52 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
[...]
Plus court: vires /etc/{DIR_COLORS, dircolors, tartampion} ~/.dir_colors, puis eval `dircolors` (rajoutes ce qui va bien pour ton shell), ls /usr/bin. Dis moi: les liens sont ils de la même couleur que les executables vers lesquels ils pointent?
Pour la nième fois, oui ! :)
Petit screenshot à l'appui :
http://magnolia.tichou.org/~tichou/dircolors.png
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
