[Résolu] Vérifier la somme de contrôle d'un fichier ?

MicP · Le 18/07/2021, à 06:56

Cette méthode permet aussi de "vider" un fichier existant de son contenu :

michel@debbull:~$ cat monFichier
Il y a 39 caractères dans monFichier.
michel@debbull:~$ ls -l monFichier 
-rw-r--r-- 1 michel michel 39 18 juil. 06:55 monFichier
michel@debbull:~$ 
michel@debbull:~$ > monFichier 
michel@debbull:~$ ls -l monFichier 
-rw-r--r-- 1 michel michel 0 18 juil. 06:56 monFichier
michel@debbull:~$

Caille · Le 18/07/2021, à 08:46

Bonjour à tous,

Merci pour tant de réponses.

J'ai donc compris le problème qui est lié à l'utilisation de l'éditeur de texte de KDE kate, il est donc préférable d'utiliser gedit.

Ce comportement de kate peut-il être assimilé à un bug, car un fichier vide doit toujours faire zéro octet ?

Nuliel a écrit :

Un fichier vide fait 0 octet, ton fichier de départ n'était pas complètement vide
Tu peux passer hexdump -C ton_fichier_vide pour voir ce qu'il contient en hexa, les deux caractères étant très probablement CR LF (carriage return line feed), donc 0d 0a
Tu as créé un fichier par le gestionnaire de fichier qui a simplement copié un fichier modèle nommé "fichier vide" qui en pratique n'est pas complètement vide. Au moins en passant par le terminal on n'a pas ce pb

Bonjour,

Effectivement j'avais été surpris que le fichier vide faisait 2 octets.

L'essai d'hier était fait depuis ma partition KDE avec l'éditeur de texte kate, vide le fichier fait bien 2 octets ?
Je viens de faire le même essai sous KDE et Gnome avec l'éditeur de texte gedit, vide le fichier fait bien 0 octet.
Dans ce cas la somme de contrôle change après avoir ajouté un caractère, mais redevient égale au fichier d'origine après l'avoir effacé !
Premier SHA256 fichier vide après création et zéro octet.
SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Après avoir ajouté le caractère 1
SHA256: 4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865
Après avoir supprimé le caractère 1
SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

C'est donc bien l'éditeur de texte de KDE (kate) qui provoque ce problème ?

[caille@caille-n76vb Bureau]$ hexdump -C Fichier_texte_8.txt
00000000  20 0a                                             | .|
00000002
[caille@caille-n76vb Bureau]$

Ci-dessous fichier de zéro octet créé par gedit sous KDE ou Gnome, il n'y a aucune réponse, le fichier est donc bien vide !

[caille@caille-n76vb Bureau]$ hexdump -C Untitled_File_1
[caille@caille-n76vb Bureau]$

FrancisFDZ · Le 18/07/2021, à 09:09

MicP a écrit :

Bonjour

FrancisFDZ a écrit :

Pour créer un fichier vraiment vide, je ne connais qu'une commande
touch mon_fichier

Il y a aussi celle-là :

> mon_fichier

michel@debbull:~$ ls -l mon_fichier
ls: impossible d'accéder à 'mon_fichier': Aucun fichier ou dossier de ce type
michel@debbull:~$ > mon_fichier
michel@debbull:~$ ls -l mon_fichier
-rw-r--r-- 1 michel michel 0 18 juil. 01:00 mon_fichier
michel@debbull:~$

Merci @MicP, je n'y aurais pas pensé tout seul ! Et j'avais oublié que touch permet de vider complètement un fichier (commande que j'utilisais il y a quelques années sous HPUX pour vider des fichiers log envahissants)

@Caille : il n'y a pas lieu d'incriminer kate, son rôle est d'éditer des fichiers, pas de créer des fichiers vides, et kate n'a rien à envier à gedit (gedit chez gnome, kate chez KDE, mais équivalents). Reste la définition d'un fichier "vide" : un fichier qui ne contient que "Cr LF" (dénomination anglophone pour "Retour chariot - Passage à la ligne", héritage des machines à écrire) est en fait "vide de texte", la présence de caractères à vocation technique ne change pas vraiment sa vacuité.
Ça tourne à la tétracapillectomie longitudinale !

[Edit] Pour les non initiés aux termes d'origine hellénique : "tétracapillectomie longitudinale" = "l'art de couper les cheveux en quatre dans le sens de la longueur" [/Edit]

Dernière modification par FrancisFDZ (Le 18/07/2021, à 09:17)

Nuliel · Le 18/07/2021, à 09:37

Je me suis trompé, CR LF c'est chez windows, chez Linux c'est que LF (ou CR LF pour rester "compatible" avec windows). C'est d'ailleurs pour cette raison que lorsque tu envoies un fichier texte de linux à windows, il peut arriver de ne pas voir les retours à la ligne sous windows.
Ici c'est bien un espace et un retour à la ligne (LF) qu'il y avait dans ton fichier.
Je pense que cela est dû au fait que lorsque tu crées un fichier, tu fais en fait une copie d'un modèle (sur gnome c'est le dossier Modèles dans ton dossier personnel), et ce modèle ne fait pas 0 octet.

xinu · Le 18/07/2021, à 10:58

FrancisFDZ a écrit :

Et j'avais oublié que touch permet de vider complètement un fichier

https://www.youtube.com/watch?v=x9lxOc8ryFk

Je sors...

jplemoine · Le 18/07/2021, à 11:27

J'ai aussi un doute mais j'avais ça en tête. C'est peut-être en Unix que ça vide le fichier.
Sous Xubuntu :

user@machine:~/testjpl$ echo "ceci est un contenu" > dummy.txt
user@machine:~/testjpl$ 
user@machine:~/testjpl$ cat dummy.txt 
ceci est un contenu
user@machine:~/testjpl$ touch dummy.txt 
user@machine:~/testjpl$ cat dummy.txt 
ceci est un contenu
user@machine:~/testjpl$

Je suis dans mon home et à priori, il n'y a pas de problème de droit.
D'après le man, ça permet de modifier la date de création et/ou de dernière modification.
Sauf si on met un paramètre (-c ou -h), ça crée un fichier vide s'il n'existe pas.

jplemoine · Le 18/07/2021, à 11:30

Suite du test :

user@machine:~/testjpl$ ls -ld dummy.txt 
-rw-rw-r-- 1 untoutseul05_20 untoutseul05_20 20 juil. 18 11:22 dummy.txt
user@machine:~/testjpl$ touch dummy.txt 
user@machine:~/testjpl$ ls -ld dummy.txt 
-rw-rw-r-- 1 untoutseul05_20 untoutseul05_20 20 juil. 18 11:27 dummy.txt
user@machine:~/testjpl$
user@machine:~/testjpl$ cat dummy.txt 
ceci est un contenu

On voit bien que l'heure passe de 11:22 à 11:27 (heure où la commande est lancée) mais que le contenu est bien toujours le même.

Dernière modification par jplemoine (Le 18/07/2021, à 11:30)

xinu · Le 18/07/2021, à 13:03

jplemoine a écrit :

J'ai aussi un doute

Je pense que FrancisFDZ est victime d'un lapsus malencontreux et comme aujourd’hui j'ai mangé du clown...

Caille · Le 19/07/2021, à 09:50

FrancisFDZ a écrit :

Ça tourne à la tétracapillectomie longitudinale !
[Edit] Pour les non initiés aux termes d'origine hellénique : "tétracapillectomie longitudinale" = "l'art de couper les cheveux en quatre dans le sens de la longueur" [/Edit]

Bonjour,

J'ai toujours pensé que cette formule concernait la coupe des cheveux en quatre dans le sens de l'épaisseur, dans le sens de la longueur c'est trop simple, la citation n'a plus aucun sens.

Bon, j'avoue que je tripatouille beaucoup sur différents forums comme ici, mais j'aime ça.

FrancisFDZ · Le 19/07/2021, à 10:21

Caille a écrit :

FrancisFDZ a écrit :
Ça tourne à la tétracapillectomie longitudinale !
[Edit] Pour les non initiés aux termes d'origine hellénique : "tétracapillectomie longitudinale" = "l'art de couper les cheveux en quatre dans le sens de la longueur" [/Edit]
Bonjour,
J'ai toujours pensé que cette formule concernait la coupe des cheveux en quatre dans le sens de l'épaisseur, dans le sens de la longueur c'est trop simple, la citation n'a plus aucun sens.
Bon, j'avoue que je tripatouille beaucoup sur différents forums comme ici, mais j'aime ça.

AMHA, ça tourne à la capillotraction !
Je pensais que "dans le sens de la longueur" impliquait que l'on conservait cette longueur. Ah, les subtilités de la langue française !

Caille · Le 19/07/2021, à 10:49

FrancisFDZ a écrit :

AMHA, ça tourne à la capillotraction !
Je pensais que "dans le sens de la longueur" impliquait que l'on conservait cette longueur. Ah, les subtilités de la langue française !

Tu as probablement raison, mais je n'avais donc pas bien compris le sens de cette phrase.

FrancisFDZ · Le 19/07/2021, à 11:32

jplemoine a écrit :

J'ai aussi un doute mais j'avais ça en tête. C'est peut-être en Unix que ça vide le fichier.
Sous Xubuntu :
user@machine:~/testjpl$ echo "ceci est un contenu" > dummy.txt
user@machine:~/testjpl$ 
user@machine:~/testjpl$ cat dummy.txt 
ceci est un contenu
user@machine:~/testjpl$ touch dummy.txt 
user@machine:~/testjpl$ cat dummy.txt 
ceci est un contenu
user@machine:~/testjpl$ 
Je suis dans mon home et à priori, il n'y a pas de problème de droit.
D'après le man, ça permet de modifier la date de création et/ou de dernière modification.
Sauf si on met un paramètre (-c ou -h), ça crée un fichier vide s'il n'existe pas.

C'était dans la décennie '90, sur HPUX.. Il me reste un doute :

touch mon_fichier

remet effectivement à l'heure le fichier concerné, Serait-ce

cat > mon_fichier

Mes souvenirs sont incertains ...
[Edit] plutôt

cat "" > mon_fichier"

, sinon je pense que la commande cat va attendre les caractères à envoyer à "mon_fichier" jusqu'à interruption de la commande (par "Ctrl-C")
La commande

> mon_fichier

qui peut se lire "(rien) dans mon_fichier" en serait une variante (ici on n'attend pas de texte à entrer) [/Edit],

Dernière modification par FrancisFDZ (Le 19/07/2021, à 11:46)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 18/07/2021, à 06:56

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#27 Le 18/07/2021, à 08:46

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#28 Le 18/07/2021, à 09:09

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#29 Le 18/07/2021, à 09:37

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#30 Le 18/07/2021, à 10:58

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#31 Le 18/07/2021, à 11:27

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#32 Le 18/07/2021, à 11:30

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#33 Le 18/07/2021, à 13:03

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#34 Le 19/07/2021, à 09:50

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#35 Le 19/07/2021, à 10:21

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#36 Le 19/07/2021, à 10:49

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

#37 Le 19/07/2021, à 11:32

Re : [Résolu] Vérifier la somme de contrôle d'un fichier ?

Pied de page des forums