Forum

Reprise du message précédent

Messages croisés!



C'est le plus important!

Bonjour,

Alors question certainement idiote, mais pourquoi ne pas lancer un : su - ./nomduscript.sh ?

Vu que cest une operation de maintenance a faire des des délais assez éloignés...

? Mais pour quoi faire ?!

Erreur d'aiguillage, c'était dans /root/.bash_profile



parce qu'en root remove-old-kernels ne voulair pas se lancer sans tout le chemin /usr/local/bin/remove-old-kernels.

Édité par Girotte Le 22/08/2022 à 19h03

Bonjour Vigen
cette commande ne fonctionne pas (du moins chez moi).

Ce qu'il est possible de faire :
su -
mot de passe
cd /répertoire_où_est_ le_script
sh remove-old-kernels.sh

Je trouve ça plutôt fastidieux

Alors effectivement j'ai écris trop vite et la commande n'est pas bonne.

Accepte mes excuses.

Avant cette commande, ont peux faire un clic droit sur le script, permissions, exécuter comme un programme (excuse-moi si le terme n'est pas précis je fais ça de mémoire).


Donc en effet après le : su -

On renseigne le mot de passe.

On se déplace dans le répertoire à l'aide de la commande : cd

Mais après, pourquoi ne pas faire un ./nomduscript.sh au lieu de sh ?

Simple question pour ma culture personnelle ?

Édité par vigen Le 22/08/2022 à 19h29

Là , en nombre de caractères à taper c'est pareil !

Car on change d'environnement, on ne partage pas le "dossier courant" avec su - du coup ./script n'est probablement pas dans ./

C'est ça !
su - nous amène dans le répertoire /root

Bonjour,

Et pourquoi pas un

su -c ./nomduscript.sh

( bon je sais que ne pas utiliser le "-" ce n' est visiblement pas bien)

Édité par nic80 Le 22/08/2022 à 22h29

Rooooh!
Mais ton script est dans ton home, pas dans / ....

Tu peux te créer la "commande" kern (ou autre terme court qui te plaira) à lancer dans le terminal en simple user.
C'est une série de commandes très faciles, et pas une seule en root.

- Tu crées un répertoire (Peut-être que tu l'as déjà.):


- Tu y places le script remove-old-kernels.sh (un copier-coller, très compliqué, wouarf!)

- Dans le gestionnaire de fichiers, tu vas dans les propriétés de remove-old-kernels.sh et dans "permissions", tu coches "Autoriser l'exécution du fichier comme un programme"

= Méthode en ligne de commande:

- Tu ouvres le fichier /home/daniel/.bash_profile avec ton éditeur de texte habituel, geany par exemple:

et tu y ajoutes à la fin la ligne:


--> Maintenant tu peux faire directement en user:


Mais c'est encore trop long à taper!!

Cette fois tu ouvres /home/daniel/.bashrc et sous les premières lignes

tu ajoutes:


Remarque: "-n3", c'est pour garder 3 kernels. On choisit le nombre qu'on veut. Si on ne passe aucune option -n, le script garde par défaut 2 kernels.
Ferme le terminal et rouvre-le pour que l'alias soit pris en compte.

--> Maintenant si tu tapes

en simple user , tu lances le script avec l'option -n que tu as écrite (et la demande de mot de passe root dans une popup).

Bien sûr, on peut choisir tout ce qu'on veut à la place de "kern", du moment que ce n'est pas une commande ou un alias qui existe déjà.

Édité par Girotte Le 22/08/2022 à 23h12

Cest pour cela que je disais dans mon premier post, après avoir tapé la commande su -
Ce deplacer dans le reprtoire cible a l'aide de la commande cd.
Puis ./nomduscript.sh

Javais parfaitement compris que le script ne se trouvais pas dans /

Mais je n'a pas du être très clair autant pour moi.

Le "problème" des alias, cest qu'au bout d'un moment tu en as beaucoup..

Personnellement, pour les taches de maintenance peu courantes j'aime bien taper la commande histoire de ne pas oublier

Mais ça c'est ma popote !

Si je devais mettre le script dans un répertoire je ne le mettrais pas dans bin Mais je chipote !

Édité par vigen Le 23/08/2022 à 06h05

En fait, tout à fait d'accord! Mais beaucoup de personnes placent leurs script dans le bin du home, et je ne voulais pas compliquer le tout.
Pour l'alias, il me semble que "remove-olds-kernels" n'est pas plus facile à retenir que "kern" (et surtout pas plus facile qu'un alias choisi par l'utilisateur, plus susceptible de le retenir. )

On peut même directement nommer son script d'un seul mot, sans ".sh", à condition de le rendre exécutable.
Mais dans ce cas, à mon sens, il y a intérêt à tenir un historique écrit de ce qu'on fait (dans CherryTree par exemple).
Alors que l'alias se retrouve tout simplement, dans la liste fournie par la commande "alias"; je ne connais rien de plus rapide!

À partir de là, si on fait:

On obtient par exemple un résultat comme:

ou

selon qu'on ait choisi d'inclure ou non l'option dans l'alias.

Personnellement je n'aime pas du tout laisser un script hors de /, où cela nécessite de s'identifier en root pour le modifier; je trouve cette précaution encore plus indispensable pour les scripts qui touchent au système (et ici aux kernels "contenus" par /boot).
Je place les scripts personnels dans /usr/local/bin (Ben oui, exécutables!) et mes fichiers desktop dans /usr/local/share/applications.
C'est-à-dire en gardant la structure qu'on trouve dans /user/bin ou /usr/local/share/applications.

Avant, je plaçais directement mes scripts et desktops avec ceux du système (Honte à moi! ), jusqu'à ce que Jybz me fasse remarquer que ce n'était pas du tout une bonne idée! Et c'est vrai qu'en passant par /usr/local, en plus de ne pas toucher aux répertoires réservés au système, on retrouve très facilement des personnalisations (Très pratique pour sauvegarder et réinstaller un jour).

Vraiment, à l'usage, c'est la façon la plus économe d'énergie et de mémoire (les miennes, pas celle de l'ordinateur), tout en gardant un côté sécurisé.
Voilà pour ma tambouille personnelle.

Édité par Girotte Le 24/08/2022 à 00h26

Merci pour cette réponse complète !

+ 1