Quand vous tombez sur un fichier commençant par un tiret, si vous vous voulez le déplacer, le renommer ou le supprimer, il vous est impossible de le faire car celui-ci sera considérer comme une option.
Voici trois façon de contourner le problème:
Avec — devant le fichier:
mv -- -fichier
Par le numéro d’inode:
ls -i
find . -inum "n° d'inode'" -exec mv {} nouveau_nom \;
Avec ./ devant le fichier:
mv ./--help toto
Le suid
Lorsque l’on place un suid sur un fichier, n’importe quel utilisateur peut l’exécuter en héritant des permissions du propriétaire, comme s’il était lui-même le propriétaire.
Le suid ne s’active que sur des fichiers.
Pour activer suid :
sudo chmod u+s fichier
Pour supprimer le suid:
sudo chmod u-s fichier
Attention à l’utilisation de suid, explication sur ce lien http://www.tofe.org/suid.php3
Le sgid
Sur un fichier ce droit fonctionne comme le droit SUID, mais appliqué aux groupes. Il donne à un utilisateur les droits du groupe auquel appartient le propriétaire de l’exécutable et non plus les droits du propriétaire.
sudo chmod g+s fichier
Sur un répertoire ce droit a une tout autre utilisation s’il est appliqué à un répertoire. Normalement, lorsqu’un fichier est créé par un utilisateur, il en est propriétaire, et un groupe par défaut lui est appliqué (généralement users si le fichier a été créé par un utilisateur, et root ou wheel s’il a été créé par root). Cependant, lorsqu’un fichier est créé dans un répertoire portant le droit SGID, alors ce fichier se verra attribuer par défaut le groupe du répertoire. De plus, si c’est un autre répertoire qui est créé dans le répertoire portant le droit SGID, ce sous-répertoire portera également ce droit.
sudo chmod g+s repertoire
Le sticky bit
Ce droit (traduction bit collant) est utilisé pour manier de façon plus subtile les droits d’écriture d’un répertoire. En effet, le droit d’écriture signifie que l’on peut créer et supprimer les fichiers de ce répertoire. Le sticky bit permet de faire la différence entre les deux droits.
Sur un fichier, Gnu/Linux n’en tient pas compte contrairement aux vieux systèmes Unix. Ainsi le sticky activé indique à l’OS que le fichier sera utilisé fréquemment et sera ainsi stocké dans un fichier d’échange pour avoir la main dessus rapidement.
sudo chmod +t fichier
Sur un répertoire le sticky bit aura pour effet d’interdire à quiconque n’étant pas le propriétaire du fichier sa suppression. Cependant, il sera toujours possible de modifier le fichier d’un autre si l’on possède les droits nécessaires.
sudo chmod +t repertoire
Pour envoyer un message à un seul utilisateur, on doit d’abord trouver le numéro de terminal » pts » que l’utilisateur utilise:
who
ce qui nous donne le résultat:
On voit que l’utilisateur utilise le pts/3 (ici par rapport à l’heure).
Donc ensuite:
echo "testeuuuu... li la louuuuu" >> /dev/pts/3
Pour envoyer un message à tous le monde, On utilise la commande Wall.
Le mieux est de créer un fichier avec notre message pour se prémunir d’une éventuelle faute de frappes.
Création du fichier et du message:
echo "Le serveur va être redémarré pour maintenance, déconnectez-vous je vous prie" >> msg_cmd_wall
Envoi du message:
wall < msg_cmd_wall
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 »
Le signe « – » n’est pas en lui-même un opérateur lorsqu’un nom de fichier est attendu, c’est plutôt une option reconnue par certains Unix et Linux. Cela écrit dans la sortie standard (stdout) ou lit dans l’entrée standard (stdin), comme par exemple tar ou cat, mais il y en a d’autre
Voici un exemple avec cat:
echo "salut" | cat -
Cela affichera:
salut
Voici un exemple avec tar:
tar -cvf - /home/starmate | ssh sauvegarde@sauvegarde.home "cat > sauvegarde.tar"
Ici tar va envoyer la création de l’archive dans la sortie standard, qui sera pipée ( | ) via SSH sur le serveur « sauvegarde.home ». Puis son affichage via cat sera redirigé dans un fichier sauvegarde.tar dans le répertoire personnel de l’utilisateur local « sauvegarde ».
Un » – » redirige donc la sortie vers stdout ou accepte une entrée de stdin, plutôt qu’un fichier.
Cette méthode est utilisé principalement lorsque l’on juge utile de manipuler des fichiers à travers des tubes.