Il a aussi le paquet sysv-rc-conf si ça cadre avec ce que tu recherches
Je l’ai par défaut sous squeeze. Par contre, je ne connais pas le paquet qui fournis cette commande, avis aux connaisseurs.
C’est bien l’équivalent de la commande service. L’argument status ne dépend pas de telle ou telle commande, mais de la façon dont à été écris le script correspondant au service présent dans /etc/init.d/
Ces scripts prennent en compte start, stop (encore heureux^^), reload, restart et des fois également l’argument status.
Ça par contre c’est l’équivalent de chkconfig qui permet de choisir le runlevel sur lequel les services doivent démarrés ou non (simplifié: les services/démons lancés au démarrage de la machine). Mais ce n’est pas si éloigné que ça de la question d’ours-blanc- ^^
Je l’ai par défaut sous squeeze. Par contre, je ne connais pas le paquet qui fournis cette commande, avis aux connaisseurs.[/quote]
À priori c’est soit chkconfig, soit sysvconfig.
Je l’ai par défaut sous squeeze. Par contre, je ne connais pas le paquet qui fournis cette commande, avis aux connaisseurs.[/quote]
Tu commande par faire un :
which servicepour savoir où se trouve le fichier exécutable.
Ensuite tu utilise cette commande qui va te dire quel paquet a installé ce fichier :
dpkg -S /chemin/serviceEn l’occurrence chez moi c’est le paquet sysvinit-utils qui me l’a installé. 
Re,
Le fait d’installer sysvinit-utils ne m’a pas installé “service” ! C’est sans doute un effet de bord qui l’a installé chez toi 
Je suis en sid, et voici ce que me renvoie la commande
sudo apt-file search service| grep "/service$"
[...]
sysvinit-utils: /usr/sbin/service
Je ne l’ai pas installé, mais cette commande est bien livrée avec le paquet sysvinit-utils .
Salut,
Merci Louis, je découvre que “which” utilisé comme simple utilisateur nous cache la réponse 
Ma solution :
L’espace entre le h et ’ est volontaire. C’est lui qui permet de prendre en compte la suite de la commande
[quote=“ggoodluck47”]Re,
Le fait d’installer sysvinit-utils ne m’a pas installé “service” ! C’est sans doute un effet de bord qui l’a installé chez toi [/quote]
$ dpkg -L sysvinit-utils
/bin/pidof
/sbin/bootlogd
/sbin/fstab-decode
/sbin/killall5
/sbin/startpar
/sbin/sulogin
/usr/bin/last
/usr/bin/lastb
/usr/bin/mesg
/usr/sbin/service
/usr/share/doc/sysvinit-utils/changelog.Debian.gz
/usr/share/doc/sysvinit-utils/changelog.gz
/usr/share/doc/sysvinit-utils/copyright
/usr/share/man/man1/last.1.gz
/usr/share/man/man1/lastb.1.gz
/usr/share/man/man1/mesg.1.gz
/usr/share/man/man8/bootlogd.8.gz
/usr/share/man/man8/fstab-decode.8.gz
/usr/share/man/man8/killall5.8.gz
/usr/share/man/man8/pidof.8.gz
/usr/share/man/man8/service.8.gz
/usr/share/man/man8/startpar.8.gz
/usr/share/man/man8/sulogin.8.gz
Tu peut voir ça dans ces pages :
[ul][li]sous lenny, il y a pas : packages.debian.org/lenny/i386/s … s/filelist[/li]
[li]à partir de squeeze, il y a packages.debian.org/squeeze/i386 … s/filelist[/li][/ul]
[quote=“ggoodluck47”]Salut,
Merci Louis, je découvre que “which” utilisé comme simple utilisateur nous cache la réponse
Ma solution :
L’espace entre le h et ’ est volontaire. C’est lui qui permet de prendre en compte la suite de la commande [/quote]
Logique which va cherche dans ton PATH et service n’est pas dans le PATH d’un simple utilisateur.
Salut,
Normal ?
Que le simple utilisateur n’ait pas le droit de le lancer : normal
Qu’il n’ait pas le droit de savoir qu’il existe ni ou il est : ?
Ben techniquement sinon which devrait faire ça :
Je te garanti que c’est plus long.
L’utilisation de sudo oblige à créer une règle spécifique et ajouterais sudo comme dépendance à switch. Si ça arrive un jour je remplacerais which par une fonction shell :
function which (){
for dir in ${(s/:/)PATH} ; do
for file in $(ls $dir) ; do
echo $dir/$file
done
done
}
D’ailleurs je viens de voir que j’utilise un builtin de mon shell et pas /usr/bin/which.
Edit: d’ailleurs tu peut toujours ajouter /sbin et /usr/sbin dans ton PATH.
Question bête, mais je n’ai pas de debian sous la main… Il me semble que quand j’avais installé Lenny pour la première fois, j’avais pas mal galéré parce qu’ifconfig ne me renvoyait rien (ou renvoyait un truc genre “commande inexistante”), alors que ça fonctionnait en root…
Me trompé-je ?
Salut,
Prends le temps de lire 3 ou 4 lignes plus haut la réponse à ta question 
J’ai vu, mais ce que je voulais dire c’est que sur le cube présenté, ifconfig est précédé de $ et qu’il faudrait plutôt le précéder de #. Ce serait un peu plus noob-friendly.
Il pourrait surtout être remplacé par netstat.
De plus à la place de vi, editor me semble mieux.
juste pour dire merci
parceque moi aussi j’étais déçu qu’il n’existe pas pour débian
maintenant je suis content lol 
C’est surtout que si le noob est amené à l’utiliser, il aura aussi besoin d’un “vi cube” 
Lol, c’est pas entièrement faux, j’avoue^^
Bon, va pour un “editor” qui semble plus à la portée des non habitués dans ce cas là.
Re,
Lol, c’est pas entièrement faux, j’avoue^^
Bon, va pour un “editor” qui semble plus à la portée des non habitués dans ce cas là.[/quote]
Et à chaque fois que vous allez améliorer je me réimprime et me reconstruit mes cubes
Lol ggoodluck47. En même temps, si tu veux les corriger directement avec du blanco/correcteur, ça risque d’être assez moche au final.
Pour le moment, pas vraiment de grosses modifs, si le cube te plaît dans l’état actuel t’es pas obligé d’en refaire un. C’est juste qu’il faut qu’il soit le plus user-friendly, mais bon pour moi je préfère un vi à un editor par exemple 
Sinon, il y a les svg sur le wiki (qu’il faut que je mettes à jour d’ailleurs =)) pour se faire son cube perso.