Étiquette : source

26 novembre 2015 /

Si vous êtes plusieurs a travailler sur un serveur, et que vous souhaitez connaître les commandes qui ont été exécutées, cela est très simple.

Pour y parvenir, il faut éditer le fichier /etc/bash.bashrc:

vi /etc/bash.bashrc

A la fin du fichier rajouter cela:
PROMPT_COMMAND='history -a >(logger -t "$USER[$PWD] $SSH_CONNECTION")'

Il n’y a plus qu’a soucer pour prendre en compte les modifications:

source /etc/bash.bashrc

Vous pouvez maintenant voir les commandes dans /var/log/messages ou /var/log/syslog (Ubuntu).

15 juin 2015 /

La commande source permet de lire et d’exécuter les commandes contenues dans un fichier passé en argument avec l’environnement du shell en cours, puis renvoie le code de retour de la dernière commande exécutée dans le fichier.

En gros, de base, un processus ne peut pas modifier l’environnement de son parent. Il ne peut modifier que son propre environnement. Il peut aussi choisir quel environnement transmettre lors d’un exec.

Quand tu exécutes un script de cette façon « ./script.sh », ton shell devient un fork dans lequel un nouveau shell va exécuter le script. Les variables du script sont placés dans l’environnement du processus fils, pas dans le processus père.

Alors que quand on « source » un fichier, cela demande au shell courant d’interpréter le script qui est passe en argument. Cela ne crée pas de sous-shell. Donc dans ce cas le script modifie bien l’environnement du shell courant.

Note que « .  » est équivalent à « source ».
Au lieu de faire « source script.sh », on peux faire « . ./script.sh ».

Exemple:

. ./script.sh

ou

source ./script.sh

Avec cette commande, on « source » le fichier script.sh contenant des fonctions ou des variables; c’est à dire que les variables contenues dans le fichier « sourcé » deviennent connues pour le shell courant, idem pour les fonctions.

Rappel:

Faites attention,  « ./  » et source ne font pas la même chose.

./script.sh lance le script comme un fichier executable, lancant un nouveau shell pour son execution.
source script.sh lis et execute les commandes/paramètres du fichier passé en argument dans le shell courant

Donc « ./script.sh » n’est pas comme « . script.sh », mais « . script.sh » est pareil que « source script.sh »

 

4 juin 2015 /

Vous pouvez avoir besoin de supprimer voire même de bloquer l’enregistrement dans l’historique des commandes exécutées.

Par exemple, à partir d’un serveur samba, si je souhaite me connecter sur un autre serveur samba, lors de cette connexion, je vais être obligé de renseigner un compte avec son mot de passe en clair:

smbclient //serveur_samba/ MDP_en_CLAIR -U Login -L serveur_samba

Pour supprimer l’historique via la commande:

history -c

On peut également supprimer une commande via son numéro dans l’historique (ici 1002):

history -d 1002

Pour supprimer l’historique de façon permanente, Il suffit d’éditer le fichier ~/.bashrc:

vi ~/.bashrc

Et soit de rajouter ça en utilisant HISTSIZE:

export HISTSIZE=0 

Où en utilisant HISTFILE:

unset HISTFILE 

Il n’y a plus qu’a recharger la configuration de .bashrc:

source ~/.bashrc

Il existe une autre solution, qui est d’ajouter un espace avant la commande à exécuter.
Chaque commande précédée d’un espace ne sera pas enregistrée dans l’historique.

Pour que cela fonctionne, il faut l’ajouter dans le fichier ~/.bashrc la présence de cette ligne si n’est pas présente:

export HISTCONTROL=ignorespace