Je peux lire depuis / dev / null; comment le réparer?

/dev/null est un fichier. Un fichier spécial Un fichier de périphérique comme / dev / sda ou / dev / tty qui communique avec un élément matériel de votre système.

La seule différence avec /dev/null est qu'aucun matériel n'est lié à celui-ci. Toutes les données que vous lui envoyez sont ignorées en silence. Comme la commande suivante:

echo "Hello World" > /dev/null

qui n'imprimera rien sur votre terminal car vous envoyez la sortie de echo à null, au vide, donc à un trou noir.

Mais quand vous avez mv test_file /dev/null , vous avez remplacé le fichier spécial /dev/null par un fichier texte normal, contenant une copie du contenu de votre test_file . En d'autres termes, vous avez perdu votre /dev/null .

Maintenant, ce que vous devez faire est (pour le reconstruire):

sudo rm /dev/null
sudo mknod -m 0666 /dev/null c 1 3

Vous devriez le reconstruire car de nombreux scripts envoient par défaut des résultats à /dev/null . Si /dev/null n'est plus un trou noir mais un fichier texte régulier, il peut s'agrandir, croître et remplir votre système de fichiers. Et je suis sûr que vous voulez éviter cela.

Et beaucoup plus dangereux, beaucoup de scripts supposent que lire de /dev/null ne lira rien; Briser cette hypothèse peut conduire à des ordures aléatoires écrites dans des fichiers tout autour de votre système ... pratiquement impossible à réparer.

Et rappelez-vous que Linux est multi-tâches: pendant que vous jouez avec /dev/null , beaucoup de processus sont en cours d'exécution et peuvent causer des dégâts même pendant quelques secondes "fenêtre d'opportunité".

Si vous voulez jouer avec /dev/null , vous pouvez créer une copie et l'expérimenter:

sudo mknod -m 0666 /tmp/null c 1 3 

Créez un fichier /tmp/null qui fonctionne exactement de la même manière que /dev/null mais que vous pouvez manipuler et tester sans aucun risque pour votre système.

Il y a une grande différence entre écraser un fichier et écrire dans un fichier .

Lorsque vous écrivez quelque chose sur /dev/null , par exemple,

$ echo Hello > /dev/null

... il est éliminé en silence. Pour cela, vous devez disposer d'autorisations en écriture sur /dev/null , que tout le monde possède:

$ ls -l /dev/null 
crw-rw-rw- 1 root root 1, 3 Mar 18 13:17 /dev/null

Lorsque vous écrasez /dev/null , comme vous l’avez fait avec la commande mv , vous remplacez le fichier spécial /dev/null par celui que vous avez déplacé. Ne faites pas cela! La raison pour laquelle vous aviez besoin des privilèges root pour le faire est que pour écraser un fichier, vous devez avoir des droits d’écriture dans le répertoire contenant le fichier . case /dev :

$ ls -ld /dev
drwxr-xr-x 16 root root 4640 Mar 18 13:17 /dev

Pour restaurer /dev/null , lancez les commandes

$ sudo rm /dev/null
$ sudo mknod -m 0666 /dev/null c 1 3

(Voir aussi U & amp; StackExchange: comment créer /dev/null )

Lorsque vous exécutez la commande

$ sudo mv test_file /dev/null

vous avez remplacé le fichier spécial /dev/null par votre fichier texte. Les tentatives ultérieures de lecture de /dev/null renvoient le contenu de votre fichier texte, et les programmes qui tentent d'utiliser /dev/null de la manière habituelle seront probablement interrompus.

Remplacer ou supprimer des fichiers de périphériques dans /dev/ nécessite des privilèges de super-utilisateur, ce qui explique pourquoi votre tentative de non-sudo a échoué avec une erreur.

Voir la réponse de Benoit pour savoir comment restaurer /dev/null manuellement, mais comme la plupart (sinon la totalité) du contenu de /dev/ est géré dynamiquement par udev, je pense qu'un simple redémarrage le corrigera probablement aussi.

Pour répondre à votre question sur ce que vous auriez dû faire, pour supprimer un fichier, vous faites:

rm test_file

Comme d’autres l’ont déclaré, / dev / null est une destination pour la sortie des programmes.