sed suppression de ligne en place sur le système de fichiers complet?

En raison d'un bug d'application non encore diagnostiqué, j'ai plusieurs centaines de serveurs avec un disque plein. Il y a un fichier qui a été rempli de lignes en double - pas un fichier journal, mais un fichier d'environnement utilisateur avec des définitions de variables (donc je ne peux pas simplement supprimer le fichier).

J'ai écrit une sedcommande simple pour vérifier les lignes ajoutées par erreur et les supprimer, et je l'ai testée sur une copie locale du fichier. Cela a fonctionné comme prévu.

Cependant, lorsque je l'ai essayé sur le serveur avec le disque plein, j'ai eu environ l'erreur suivante (c'est de la mémoire, pas de copier-coller):

sed: couldn't flush /path/to/file/sed8923ABC: No space left on deviceServerHostname

Bien sûr, je sais qu'il n'y a plus d'espace. C'est pourquoi j'essaie de supprimer des trucs! (La sedcommande que j'utilise réduira un fichier de plus de 4000 lignes à environ 90 lignes.)

Ma sedcommande est justesed -i '/myregex/d' /path/to/file/filename

Existe-t-il un moyen d'appliquer cette commande malgré le disque plein?

(Il doit être automatisé, car je dois l'appliquer à plusieurs centaines de serveurs comme solution rapide.)

_{(Évidemment, le bogue d'application doit être diagnostiqué, mais en attendant, les serveurs ne fonctionnent pas correctement ....)}

Mise à jour: La situation à laquelle j'ai été confrontée a été résolue en supprimant quelque chose d'autre que j'ai découvert que je pouvais supprimer, mais j'aimerais toujours la réponse à cette question, qui serait utile à l'avenir et pour d'autres personnes.

/tmpest un non-go; c'est sur le même système de fichiers.

Avant de libérer de l'espace disque, j'ai testé et découvert que je pouvais supprimer les lignes en viouvrant le fichier et en l'exécutant :g/myregex/d, puis en enregistrant avec succès les modifications avec :wq. Il semble qu'il devrait être possible d'automatiser cela, sans avoir recours à un système de fichiers distinct pour contenir un fichier temporaire .... (?)

L' -ioption n'écrase pas vraiment le fichier d'origine. Il crée un nouveau fichier avec la sortie, puis le renomme avec le nom de fichier d'origine. Comme vous n'avez pas de place sur le système de fichiers pour ce nouveau fichier, il échoue.

Vous devrez le faire vous-même dans votre script, mais créez le nouveau fichier sur un système de fichiers différent.

De plus, si vous supprimez simplement des lignes qui correspondent à une expression rationnelle, vous pouvez utiliser à la grepplace de sed.

grep -v 'myregex' /path/to/filename > /tmp/filename && mv /tmp/filename /path/to/filename

En général, il est rarement possible pour les programmes d'utiliser le même fichier en entrée et en sortie - dès qu'il commence à écrire dans le fichier, la partie du programme qui lit le fichier ne verra plus le contenu d'origine. Il doit donc d'abord copier le fichier d'origine quelque part, ou écrire dans un nouveau fichier et le renommer une fois terminé.

Si vous ne souhaitez pas utiliser de fichier temporaire, vous pouvez essayer de mettre en cache le contenu du fichier en mémoire:

file=$(< /path/to/filename)
echo "$file" | grep -v 'myregex' > /path/to/filename

Voilà comment ça sedmarche. Si utilisé avec -i(modifier sur place) sedcrée un fichier temporaire avec le nouveau contenu du fichier traité. Une fois terminé sed, remplace le fichier de travail actuel par le fichier temporaire. L'utilitaire ne modifie pas le fichier sur place . C'est exactement le comportement de chaque éditeur.

C'est comme si vous exécutiez la tâche suivante dans un shell:

sed 'whatever' file >tmp_file
mv tmp_file file

À ce stade sed, essaie de vider les données mises en mémoire tampon dans le fichier mentionné dans le message d'erreur avec l' fflush()appel système:

Pour les flux de sortie, fflush()force l'écriture de toutes les données tamponnées de l'espace utilisateur pour le flux de sortie ou de mise à jour donné via la fonction d'écriture sous-jacente du flux.

Pour votre problème, je vois une solution dans le montage d'un système de fichiers séparé (par exemple tmpfs, si vous avez suffisamment de mémoire ou un périphérique de stockage externe) et déplacer certains fichiers là-bas, les traiter là-bas et les reculer.

Depuis la publication de cette question, j'ai appris qu'il exs'agit d'un programme compatible POSIX. Il est presque universellement lié à vim, mais de toute façon, ce qui suit est (je pense) un point clé exà propos des systèmes de fichiers (extrait de la spécification POSIX):

Cette section utilise le terme tampon d'édition pour décrire le texte de travail actuel. Aucune implémentation spécifique n'est impliquée par ce terme. Toutes les modifications d'édition sont effectuées sur le tampon d'édition, et aucune modification ne doit affecter un fichier jusqu'à ce qu'une commande de l'éditeur écrive le fichier.

"... affectera n'importe quel fichier ..." Je crois que mettre quelque chose sur le système de fichiers (même un fichier temporaire) compterait comme "affectant n'importe quel fichier". Peut être?*

Une étude attentive des spécifications POSIX pourex indiquer certains "pièges" sur son utilisation portable prévue par rapport aux utilisations scriptées courantes de la exrecherche en ligne (qui sont jonchées de vimcommandes spécifiques).

1. L'implémentation +cmdest facultative selon POSIX.
2. Autoriser plusieurs -coptions est également facultatif.
3. La commande globale :g"mange" tout jusqu'au prochain saut de ligne non échappé (et l'exécute donc après chaque correspondance trouvée pour l'expression régulière plutôt qu'une fois à la fin). Alors -c 'g/regex/d | x'supprime seulement une instance, puis quitte le fichier.

Donc, selon ce que j'ai recherché, la méthode compatible POSIX pour éditer sur place un fichier sur un système de fichiers complet pour supprimer toutes les lignes correspondant à une expression rationnelle spécifique, est:

ex -sc 'g/myregex/d
x' /path/to/file/filename

Cela devrait fonctionner si vous disposez de suffisamment de mémoire pour charger le fichier dans un tampon.

_{* Si vous trouvez quelque chose qui indique le contraire, veuillez le mentionner dans les commentaires.}

Utilisez le tuyau, Luke!

Lire le fichier | filtre | répondre

sed 's/PATTERN//' BIGFILE | dd of=BIGFILE conv=notrunc

dans ce cas, sedne crée pas de nouveau fichier et envoie simplement une sortie redirigée vers ddlaquelle ouvre le même fichier . Bien sûr, on peut utiliser grepdans un cas particulier

grep -v 'PATTERN' BIGFILE | dd of=BIGFILE conv=notrunc

puis tronquez le reste.

dd if=/dev/null of=BIGFILE seek=1 bs=BYTES_OF_SED_OUTPUT

Comme indiqué dans d'autres réponses, sed -ifonctionne en copiant le fichier dans un nouveau fichier dans le même répertoire , en apportant des modifications au processus, puis en déplaçant le nouveau fichier sur l'original. Voilà pourquoi cela ne fonctionne pas.  ed(l'éditeur de ligne d'origine) fonctionne d'une manière quelque peu similaire, mais, la dernière fois que j'ai vérifié, il utilise /tmple fichier de travail. Si votre /tmpsystème de fichiers est différent de celui qui est plein, il edpeut faire le travail pour vous.

Essayez ceci (à l'invite de votre shell interactif):

$ ed / chemin / vers / fichier / nom de fichier
P
g / myregex / d
w
q

Le P(qui est un P majuscule ) n'est pas strictement nécessaire. Il active les invites; sans cela, vous travaillez dans le noir, et certaines personnes trouvent cela déconcertant. Les wet qsont w rite et q uit.

edest connu pour les diagnostics cryptiques. Si à un moment donné, il affiche autre chose que l'invite (qui est *) ou quelque chose qui est clairement une confirmation de la réussite de l'opération ( surtout s'il contient un ?), n'écrivez pas le fichier (avec w). Quittez ( q). Si cela ne vous laisse pas sortir, essayez de qrépéter.

Si votre /tmprépertoire se trouve sur le système de fichiers qui est plein (ou si son système de fichiers est également plein), essayez de trouver de l'espace quelque part. le chaos a mentionné le montage d'un tmpfs ou d'un périphérique de stockage externe (par exemple, un lecteur flash); mais, si vous avez plusieurs systèmes de fichiers et qu'ils ne sont pas tous pleins, vous pouvez simplement utiliser l'un des autres systèmes existants. chaos suggère de copier le (s) fichier (s) vers l'autre système de fichiers, de les éditer là (avec sed), puis de les recopier. À ce stade, c'est peut-être la solution la plus simple. Mais une alternative serait de créer un répertoire accessible en écriture sur un système de fichiers qui a de l'espace libre, de définir une variable d'environnement TMPDIRpour pointer vers ce répertoire, puis de l'exécuter ed. (Divulgation: je ne sais pas si cela fonctionnera, mais cela ne peut pas faire de mal.)

Une fois que vous commencez à edtravailler, vous pouvez automatiser cela en faisant

ed nom de fichier << EOF
g / myregex / d
w
q
EOF

dans un script. Ou , comme l'a suggéré don_crissti.printf '%s\n' 'g/myregex/d' w q | ed -s filename

Vous pouvez tronquer le fichier assez facilement si vous pouvez obtenir le nombre d'octets à votre décalage et vos lignes se produisent d'un point de départ jusqu'à la fin.

o=$(sed -ne'/regex/q;p' <file|wc -c)
dd if=/dev/null of=file bs="$o" seek=1

Ou bien si votre ${TMPDIR:-/tmp}est sur un autre système de fichiers peut-être:

{   cut -c2- | sed "$script" >file
} <file <<FILE
$(paste /dev/null -)
FILE

Parce que (la plupart) des coquilles y placent leurs documents ici dans un fichier temporaire supprimé. Il est parfaitement sûr tant que le <<FILEdescripteur est maintenu du début à la fin et ${TMPDIR:-/tmp}dispose d'autant d'espace que nécessaire.

Les shells qui n'utilisent pas de fichiers temporaires utilisent des tuyaux, et ne sont donc pas sûrs à utiliser de cette façon. Ces coquilles sont généralement ashdérivés comme busybox, dash, BSD sh- zsh, bash, kshet le shell Bourne, cependant, tous les fichiers temporaires d'utilisation.

apparemment, j'ai écrit un petit programme shell en juillet dernier pour faire quelque chose de très similaire

Si ce /tmpn'est pas viable, tant que vous pouvez mettre le fichier en mémoire quelque chose comme ...

sed 'H;$!d;x' <file | { read v &&
sed "$script" >file;}

... comme un cas général garantirait au moins que le fichier a été entièrement tamponné par le premier sedprocessus avant d'essayer de tronquer le fichier d'entrée / sortie.

Une solution plus ciblée - et efficace - pourrait être:

sed '/regex/!H;$!d;x' <file|{ read v && cat >file;}

... car cela ne dérangerait pas les lignes de mise en mémoire tampon que vous vouliez supprimer de toute façon.

Un test du cas général:

{   nums=/tmp/nums
    seq 1000000 >$nums
    ls -lh "$nums"
    wc -l  "$nums"
    sed 'H;$!d;x' <$nums | { read script &&  ### read always gets a blank
    sed "$script" >$nums;}
    wc -l  "$nums"
    ls -lh "$nums"
}

-rw-r--r-- 1 mikeserv mikeserv 6.6M Dec 22 20:26 /tmp/nums
1000000 /tmp/nums
1000000 /tmp/nums
-rw-r--r-- 1 mikeserv mikeserv 6.6M Dec 22 20:26 /tmp/nums

Cette réponse emprunte des idées à cette autre réponse et à cette autre réponse, mais s'appuie sur elles, créant une réponse plus généralement applicable:

num_bytes = $ (sed '/ myregex / d' / chemin / vers / fichier / nom de fichier | wc -c)
sed '/ myregex / d' / chemin / vers / fichier / nom de fichier 1 <> / chemin / vers / fichier / nom de fichier 
dd if = / dev / null of = / chemin / vers / fichier / nom de fichier bs = "$ num_bytes" = 1

La première ligne exécute la sedcommande avec une sortie écrite sur la sortie standard (et non dans un fichier); spécifiquement, à un tuyau wcpour compter les caractères. La deuxième ligne exécute également la sedcommande avec une sortie écrite sur la sortie standard, qui, dans ce cas, est redirigée vers le fichier d'entrée en mode de lecture / écriture par écrasement (pas de troncature), qui est abordé ici . C'est une chose quelque peu dangereuse à faire; il n'est sûr que lorsque la commande de filtre n'augmente jamais la quantité de données (texte); c'est-à-dire que pour chaque n octet qu'il lit, il écrit n octets ou moins. C'est, bien sûr, vrai pour la sed '/myregex/d'commande; pour chaque ligne qu'il lit, il écrit exactement la même ligne, ou rien. (Autres exemples:s/foo/fu/ou s/foo/bar/serait en sécurité, mais s/fu/foo/et s/foo/foobar/ne serait pas.)

Par exemple:

$ cat filename
It was
a dark and stormy night.
$ sed '/was/d' filename 1<> filename
$ cat filename
a dark and stormy night.
night.

parce que ces 32 octets de données:

I  t     w  a  s \n  a     d  a  r  k     a  n  d     s  t  o  r  m  y     n  i  g  h  t  . \n

a été remplacé par ces 25 caractères:

a     d  a  r  k     a  n  d     s  t  o  r  m  y     n  i  g  h  t  . \n

laissant les sept octets night.\nà la fin.

Enfin, la ddcommande recherche la fin des nouvelles données nettoyées (octet 25 dans cet exemple) et supprime le reste du fichier; c'est-à-dire qu'il tronque le fichier à ce point.

Si, pour une raison quelconque, l' 1<>astuce ne fonctionne pas, vous pouvez le faire

sed '/ myregex / d' / chemin / vers / fichier / nom de fichier | jj de = / chemin / vers / fichier / nom de fichier conv = notrunc

Notez également que tant que vous ne faites que supprimer des lignes, tout ce dont vous avez besoin est grep -v myregex(comme l'a souligné Barmar ).

sed -i 'd' / chemin / vers / fichier / nom de fichier