Vous n'êtes pas identifié(e).
Oui je suis sur le cul, je précise que j'ai réinstallé la bestiole en pensant que c'est dù à mon upgrade mais non... Et vous ça donne quoi?
Dernière modification par seb95 (26-07-2019 12:12:24)
Hors ligne
Pour devenir « root », il faudra que tu utilises à présent :
ou
ou encore
Sinon, tu n'auras pas le répertoire /usr/sbin dans ton PATH,
et par conséquent le shell ne trouvera pas dpkg-reconfigure ainsi que
de nombreux autres programmes.
Hors ligne
au moins tu restes en root tant que tu fermes pas le terminal
Dernière modification par trapik (14-07-2019 23:49:29)
Hors ligne
Hors ligne
Mais je ne trouve pas que c'est une bonne pratique. Ceci dit, j'utilise « su » mais
je le tape rarement au clavier. Dans openbox j'ai créé un raccourci clavier pour
lancer la commande :
Bref je suis très paresseux
Hors ligne
Hors ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
En quoi c'est mieux ? Différentes manières d'atteindre le même but, moi je dirais ^^'
Je ne sais pas si mettre le PATH dans le .profile fonctionne car
ce fichier ne devrait être lu que par les shells de login, ce qui n'est pas le cas
lorsqu'on utilise « su » tout court… ou est-ce que je me trompe ?
Hors ligne
Hello
Attention avec les alias, je me souviens d'un poste ou on a découvert au bout de 3 pages pourquoi la commande tar ne fonctionnait pas justement parque l'utilisateur avait eu la bonne idée d'appeler son alias tar
C'est bien ce que je dis, ce n'est pas une bonne pratique. Ça dépend
comment on l'utilise. Quelques alias que j'utilise couramment sont :
Après on peut toujours utiliser la commande originale en faisant :
par exemple. « command » fait partie des commandes internes de bash (comme
alias d'ailleurs). je pense que c'est pareil avec zsh.
Hors ligne
Hors ligne
T'as possiblement raison, et en ce cas, bashrc, hein.
pas de soucis
Hors ligne
Efface toutes les variables d'environnement sauf TERM et les variables spécifiées
par --whitelist-environment
Initialise les variables d'environnement HOME, SHELL, USER, LOGNAME, et PATH
Va dans le répertoire HOME de l'utilisateur cible
positionne l'argv[0] du shell à « - » pour que celui se comporte comme un shell de login
En plus de cela il est recommandé d'utiliser « su -l » ou « su --login » plutôt
que « su - » pour une raison qui me paraît obscure lié au mélange possible d'environnement.
Je pense que « su - » ne se comporte pas toujours de la même manière suivant
que c'est la version linux, bsd, etc…
Voilà j'espère que ça motivera les plus récalcitrants à changer leurs habitudes
Hors ligne
ou
mais j'ai jamais fait de mon coté, j'ai appris su alors je suis resté avec su et ce même lorsque tout le monde disait que sudo était mieux.
J'ai pas cherché mais je vais y aller de ce pas, pourrait on me dire pourquoi et en quoi c'est different le su - que su tout seul?
Et pourquoi ça ne posait pas de soucis avant et sur buster c'est plus le cas?
Hors ligne
Maintenant pour revenir à notre copain SU, et bien je suis surpris, oui j'ai déjà vu bon nombre de personne faire un
su -
ou
su -l
mais j'ai jamais fait de mon coté, j'ai appris su alors je suis resté avec su et ce même lorsque tout le monde disait que sudo était mieux.
J'ai pas cherché mais je vais y aller de ce pas, pourrait on me dire pourquoi et en quoi c'est different le su - que su tout seul?
Et pourquoi ça ne posait pas de soucis avant et sur buster c'est plus le cas?
Parce qu'avant le « su » seul n'aurait jamais du se comporter comme
« su -l », mais c'était le cas. En quelque sorte le « su » d'avant ne
respecter pas la norme posix, alors que maintenant, il la respecte.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne