Comment éditer des fichiers texte multi-gigaoctets? Vim ne fonctionne pas = (

Existe-t-il des éditeurs qui peuvent éditer des fichiers texte de plusieurs gigaoctets, peut-être en ne chargeant que de petites portions en mémoire en même temps? Il ne semble pas que Vim puisse le gérer = (

Si vous êtes sur * nix (et en supposant que vous ne deviez modifier que des parties de fichier (et rarement)), vous pouvez diviser les fichiers (en utilisant la commande split ), les éditer individuellement (en utilisant awk , sed ou quelque chose de similaire) et concaténer eux après que vous avez terminé.

 cat file2 file3 >> file1 

Ctrl-C arrêtera le chargement du fichier. Si le fichier est suffisamment petit, vous avez peut-être eu la chance d’avoir chargé tout le contenu et de simplement tuer les étapes de post-chargement. Vérifiez que le fichier entier a été chargé lors de l’utilisation de cette astuce.

Vim peut très bien gérer les gros fichiers. Je viens d’éditer un fichier 3.4GB, en supprimant des lignes, etc. Trois choses à garder à l’esprit:

  1. Appuyez sur Ctrl-C: Vim essaie de lire tout le fichier initialement, pour faire des choses comme la coloration syntaxique et le nombre de lignes dans le fichier, etc. Ctrl-C annulera cette énumération nécessaire d’afficher sur votre écran.
  2. En lecture seule: Vim démarrera probablement en lecture seule lorsque le fichier est trop volumineux pour créer un fichier. copie de fichier pour effectuer les modifications sur. Je devais w! pour enregistrer le fichier, et c’est à ce moment que cela a pris le plus de temps.
  3. Aller à la ligne: En tapant :115355 amènera directement à la ligne 115355, qui est beaucoup plus rapide dans ces gros fichiers. Vim semble commencer à numériser depuis le début à chaque fois qu’il charge un tampon de lignes, et maintenir la touche Ctrl-F enfoncée pour parcourir le fichier semble devenir très lent vers la fin.

Remarque – Si votre instance Vim est en lecture seule car vous appuyez sur Ctrl-C, il est possible que Vim n’ait pas chargé le fichier entier dans le tampon. Si cela se produit, sa sauvegarde ne sauvegarde que ce qui se trouve dans le tampon, pas le fichier entier . Vous pouvez rapidement vérifier avec un G pour passer à la fin pour vous assurer que toutes les lignes de votre fichier sont là.

Ce sont peut-être des plugins qui l’étouffent. (coloration syntaxique, plis etc.)

vous pouvez lancer vim sans plugins.

 vim -u "NONE" hugefile.log 

C’est minimaliste mais ça vous donnera au moins les vi habituées.

 syntax off 

est une autre évidente. Taillez votre installation et trouvez ce dont vous avez besoin. Vous découvrirez ce dont il est capable et si vous devez accomplir une tâche par d’autres moyens.

Une légère amélioration de la réponse donnée par @Al pachio avec la solution split + vim vous permet de lire les fichiers avec un glob, en utilisant efficacement les blocs de fichiers comme tampon, par exemple

 $ split -l 5000 myBigFile xaa xab xac ... $ vim xa* #edit the files :nw #skip forward and write :n! #skip forward and don't save :Nw #skip back and write :N! #skip back and don't save 

Vous pourriez vouloir vérifier ce plug-in VIM qui désactive certaines fonctionnalités de vim dans l’intérêt de la vitesse lors du chargement de fichiers volumineux.

J’ai essayé de le faire, principalement avec des fichiers d’environ 1 Go lorsque je devais apporter de petites modifications à un dump SQL. Je suis sous Windows, ce qui en fait un problème majeur. C’est sérieusement difficile

La question évidente est “pourquoi avez-vous besoin?” Je peux vous dire par expérience que vous devez essayer plus d’une fois, vous voulez probablement essayer de trouver un autre moyen.

Alors comment tu le fais? Il y a plusieurs façons de le faire. Parfois, je peux obtenir vim ou nano pour ouvrir le fichier et je peux les utiliser. C’est une douleur vraiment difficile, mais ça marche.

Lorsque cela ne fonctionne pas (comme dans votre cas), vous n’avez que quelques options. Vous pouvez écrire un petit programme pour apporter les modifications dont vous avez besoin (par exemple, rechercher et remplacer). Vous pouvez utiliser un programme de ligne de commande capable de le faire (peut-être que cela peut être fait avec sed / awk / grep / etc?)

Si ceux-ci ne fonctionnent pas, vous pouvez toujours diviser le fichier en morceaux (quelque chose comme split étant le choix évident, mais vous pouvez utiliser head / tail pour obtenir la partie souhaitée), puis éditer la ou les parties qui en ont besoin, et recombiner plus tard.

Croyez-moi cependant, essayez de trouver un autre moyen.

Je pense que les éditeurs hexadécimaux peuvent raisonnablement manipuler des fichiers volumineux. Sous Windows, j’utilise HxD , qui prétend gérer des fichiers jusqu’à 8 EB (8 milliards de gigaoctets).

J’utilise vim 7.3.3 sur Win7 x64 avec le plugin LargeFile de Charles Campbell pour gérer des fichiers texte de plusieurs gigaoctets. Ca marche vraiment bien.

J’espère que tu viens bien.

Wow, jamais réussi à obtenir vim à s’étouffer, même avec un GB ou deux. J’ai entendu dire qu’UltraEdit (sur Windows) et BBEdit (sur Mac) sont encore plus adaptés à des fichiers encore plus gros, mais je n’ai aucune expérience personnelle.

Dans le passé, j’ai ouvert un fichier de 3 gig avec cet outil http://csved.sjfrancke.nl/

J’ai utilisé TextPad pour les gros fichiers journaux, il n’a pas de limite supérieure.

Personnellement, j’aime UltraEdit . Voici leur petit spiel sur les gros fichiers .

J’ai utilisé l’éditeur / visualiseur intégré de FAR Commander pour les fichiers journaux de très grande taille.

La seule chose que j’ai pu utiliser pour quelque chose comme ça est mon éditeur Mac hex préféré, 0XED. Cependant, c’était avec des fichiers que je considérais importants à des dizaines de mégaoctets. Je ne suis pas sûr de savoir jusqu’où ça ira. Je suis à peu près sûr qu’il ne charge que des parties du fichier en mémoire.

Dans le passé, j’ai utilisé avec succès une approche split / edit / join lorsque les fichiers étaient très volumineux. Pour que cela fonctionne, vous devez savoir où se trouve le texte à modifier, dans le fichier d’origine.