Supprimer les N premières lignes d'un fichier dans la ligne de commande unix

Je suis en train de supprimer le premier 37 lignes à partir d'un très, très gros fichier. J'ai commencé à essayer de sed et awk, mais ils semblent exiger la copie les données dans un nouveau fichier. Je suis à la recherche d'un "supprimer des lignes à la place" de la méthode, que, contrairement à sed -i n'est pas de faire des copies de tout genre, mais plutôt est juste de retirer les lignes du fichier existant.

Voici ce que j'ai fait...

awk 'NR > 37' file.xml > 'f2.xml'
sed -i '1,37d' file.xml

Ces deux semblent faire une copie complète. Est-il un autre simple CLI qui peuvent le faire rapidement, sans un document complet de la traversée?

Les deux sed -i et gawk v4.1 -i -inplace options sont fondamentalement de la création de fichier temporaire dans les coulisses. OMI sed devrait être plus rapide que tail et awk.

OriginalL'auteur Mittenchops | 2013-06-26

  1. 10

    Il n'y a pas de façon simple de le faire en place d'édition en utilisant des utilitaires UNIX, mais voici une inplace la modification de fichier de solution que vous pourriez être en mesure de modifier le travail pour vous (avec l'aimable autorisation de Robert Bonomi à https://groups.google.com/forum/#!topic/comp.unix.shell/5PRRZIP0v64):

    count=$(head -37 "$file" |wc -c)
dd if="$file" bs="$count" skip=1 of="$file"

    Le fichier final devrait être $count octets plus petite que l'originale (puisque le but était de supprimer $count octets à partir du début), donc, pour terminer, nous devons supprimer la dernière $count octets. Sur un système GNU Linux ceci peut être accompli par:

    truncate -s "-$count" "$file"

    Voir le google groupes thread que j'ai référencé pour d'autres suggestions et d'informations.

    Sur linux, vous aurez envie d'utiliser conv=notrunc dans dd, sinon, la commande échoue. +1.
    Je pense que cela peut avoir travaillé dans mon fichier avait l'air correct, mais il semblait également faire de nouvelles écrit que j'ai résilié. Alors, j'ai écrit un fichier nommé cutter.sh qui contenait #!/bin/bash file=enwiki-latest-pages-articles.xml count=`head -37 "$file" |wc -c` dd if="$file" bs="$count" skip=1 of="$file" conv=notrunc
    Il a couru pour un très long moment, puis quand j'ai C-c recommencer, terminé avec: ^C1223734+0 records in 1223734+0 records out 2902697048 bytes (2.9 GB) copied, 59.699 s, 48.6 MB/s Cependant, mes données /cherche/ fine. Puis-je faire confiance à son intégrité d'avoir à couper? Il ne semble pas comme 2.9 GO nécessaires pour être copié 37 de courtes lignes de données.
    Mieux est d'aller demander à la comp.unix.coque de groupe de discussion où tous les spécialistes des coquillages traîner.
    Ceci est mentionné dans le Google Groupes thread, mais jamais écrit: vous avez à couper le final $count d'octets à partir de la fin du fichier lorsque vous avez terminé. J'ai édité votre réponse afin de refléter cette sorte de futurs lecteurs d'avoir une solution complète.

    OriginalL'auteur Ed Morton

  2. 6

    De fichiers Unix sémantique ne permettent pas de tronquer la partie avant d'un fichier.

    Toutes les solutions seront basées sur:

    1. De la lecture du fichier en mémoire, puis de l'écrire (ed, ex, d'autres éditeurs). Cela devrait être bien si votre fichier est <1 go ou si vous avez beaucoup de RAM.
    2. L'écriture d'un deuxième exemplaire et éventuellement le remplacement de l'original (sed -i, awk/tail > foo). C'est très bien aussi longtemps que vous disposez d'assez d'espace disque pour une copie, et ne me dérange pas d'attendre.

    Si le fichier est trop gros pour que tout cela fonctionne pour vous, vous pouvez être en mesure de travailler autour d'elle en fonction de ce qui est de la lecture de votre fichier.

    Peut-être votre lecteur ignore les commentaires ou les lignes blanches? Si oui, vous pouvez alors préparer un message le lecteur ignore, assurez-vous qu'il a le même nombre d'octets que les 37 premières lignes dans votre fichier et remplacer le début du fichier avec dd if=yourdata of=file conv=notrunc.

    Hmm, n'avait pas pensé à cela. Si je devais le faire au moment de bunzip2-ing le fichier---vous dites que je voudrais tuyau de la décompression de awk et que le outfile? Donc, ce serait quelque chose comme bunzip2 filename.xml.bz2 | awk 'NR > 37' filename.xml
    yep, en faisant que lors de la décompression serait également juste de flux de le copier et de les écrire sur le disque que la modification du fichier.

    OriginalL'auteur that other guy

  3. 4

    ed est le standard de l'éditeur:

    ed -s file <<< $'1,37d\nwq'
    C'est à l'aide d'un tampon, pas mieux qu'un fichier temporaire.
    +1 c'était rapide. fichier avec 1m d'entrées - $ time ed -s ff <<< $'1,37d\nwq' real 0m0.251s user 0m0.219s sys 0m0.032s $ time sed -i '1,37d' ff real 0m1.415s user 0m0.399s sys 0m1.016s
    bien sûr, c'est que l'éditeur ne :) encore, il pourrait être plus rapide que sed ou awk...
    Je vais tester cette après mon fichier ré-ouvre. Le record est d'environ 9 GO, donc j'espère que ce n'est pas de mise en mémoire tampon. =)
    L'OP semble être à la recherche de la solution qui a vraiment fait la modification sur place mais, pas un qui utilise un fichier temp/tampon sinon, il pourrait tout aussi bien utiliser sed ou awk.

    OriginalL'auteur gniourf_gniourf

  4. 2

    La copie devra être créé à un certain point - pourquoi pas sur le temps de lecture de la "modifié" fichier; streaming la modification de l'exemplaire au lieu de les stocker?

    Ce que je pense, - créer un tube nommé "fichier2", c'est la sortie de cette même awk 'NR > 37' file.xml ou que ce soit; alors que celui qui lit fichier2 ne verrez pas le premier 37 lignes.

    L'inconvénient c'est qu'il va exécuter awk chaque fois que le fichier est traité, il est donc possible que si il est lu rarement.

    OriginalL'auteur Peteris