moins de nom de fichier

Depuis la ligne de commande, il vous permet de visualiser les fichiers immédiatement sans charger le fichier complet en mémoire.

Je n'essaierais pas de l'ouvrir ... Je préfère le faire:

1. grep - recherchez du texte
2. split - découpez le fichier en morceaux de 10 Mo, par exemple.

Quelque chose comme:

  grep "crash" My80GbFile.txt |plus
 

Si le gros fichier n'est pas "délimité par une ligne"

  split -b 10M My80GbFile.txt
 

Mais si le gros fichier est juste une charge de lignes, alors (comme cela a été publié), divisé par ligne (100 000 par sous-fichier) dans ce cas.

  split -l 100000 My80GbFile.txt
 

En ce qui concerne vos besoins immédiats, le meilleur éditeur visuel gratuit pour macOS est BBEdit (lié au téléchargement du Mac App Store) et il fait tellement - une véritable centrale électrique. Une fois que vous l'avez, vous pouvez également payer pour les fonctionnalités pro / automatisation / par gratitude, mais c'est gratuit pour toujours si vous le souhaitez et aimez ce prix.

• https://www.barebones.com/products/bbedit/index.html
• https://apps.apple.com/us/story/id1485320067

J'utilise également vi pour éditer des choses, mais cela ouvre une boîte de vers pour avoir besoin du shell, de l'application de terminal ou d'une autre application et que certains étudient pour apprendre comment quitter l'éditeur (tldr; essayez ZZ ou ZQ), personnalisez-le et apprenez à votre cerveau à penser à opérer sur du texte dans l'abstrait plutôt qu'à utiliser la souris pour sélectionner des éléments. En outre, un pager comme less ou more ou bat est également très convivial pour démarrer et naviguer dans des fichiers volumineux. (Et bat vous donne des ailes superbes couleurs et connaissance de la syntaxe).

  brew install bat
 

Dans votre cas, l'application console fournie avec macOS pourrait également valoir la peine d'être examinée si vous pouvez y utiliser la fonctionnalité de recherche. Lancez l'application à partir des projecteurs et faites glisser votre fichier monstre sur la fenêtre pour avoir un aperçu.

Juste ne pas (ouvrez-le comme UN fichier)

Y a-t-il une raison spécifique pour laquelle vous ne pouvez pas simplement le diviser en morceaux d'environ 1 Go avec un script?

Oui, la recherche et les fonctionnalités similaires en souffriront, mais ce sera déjà le cas avec un fichier de 80 Go.

Si vous avez des points d'arrêt spécifiques dans le script (jours dans l'horodatage, messages de démarrage / arrêt), vous pouvez également le diviser pour cela.De cette façon, vous auriez probablement même une signification supplémentaire dans le fichier.

Aussi: une fois divisé, tout IDE décent (comme IntelliJ IDEA ou tout autre) vous donnera une fonctionnalité de recherche sur le texte en arrière.

[Attention: cela vient d'un programmeur donc ce n'est peut-être pas votre approche ou exagéré, je peux seulement dire que cela fonctionnera à la fin, vous devrez savoir si cela en vaut la peine]

1. Utilisez less dans une fenêtre de terminal. Il ne vous montrera qu'une page à la fois du fichier, ne chargera que cela en mémoire, vous pouvez donc naviguer dans des fichiers multi-TB si vous le souhaitez.

   Vous devriez probablement ajouter l'option -n pour empêcher less d'essayer de calculer les numéros de ligne. Donc:

     moins -n / chemin / vers / fichier
    

   N'oubliez pas que vous pouvez taper less -n (n'oubliez pas l'espace final) et glisser-déposer le fichier du Finder vers la fenêtre du Terminal pour ajouter le chemin d'accès à ce fichier.

2. Une fois que vous affichez le fichier en less , vous pouvez:

   • naviguer à l'aide des flèches haut / bas, espace (une page vers le bas), b (une page en arrière) ...
   • recherche en utilisant / . Vous pouvez également rechercher des lignes ne contenant pas de motif avec /! . La recherche inversée utilise ? . Mais toutes les recherches analyseront le fichier entier. Mieux vaut l'avoir sur un SSD si vous faites beaucoup ça.
   • accédez à une ligne spécifique du fichier en utilisant <number> suivi de G (G majuscule)
   • accédez à une partie spécifique du fichier en utilisant <number> suivi de % . Ainsi, 50% vous amènera au milieu du fichier, 90% aux 10 derniers%, etc.

Si votre fichier journal a des horodatages et que vous savez quand vous voulez regarder, l'approche la plus rapide est de:

1. ouvrez le fichier

2. Utilisez une "recherche binaire" pour trouver la partie approximative du fichier qui vous intéresse:

   • Tapez 50% , qui vous montrera le milieu du fichier
   • Si la partie que vous voulez est après, passez à 75% , sinon 25%
   • Répétez jusqu'à ce que vous soyez réduit à la partie appropriée

3. Utilisez une recherche régulière (en utilisant / pour avancer ou ? pour revenir en arrière) pour trouver la ligne exacte que vous recherchez (basée soit sur l'horodatage exact ou un mot spécifique que vous connaissez indique le problème).

Cela devrait vous permettre de naviguer rapidement et rapidement vers la partie pertinente du fichier.

Si vous pensez avoir beaucoup de recherches dans un sous-ensemble du fichier, vous pouvez également utiliser grep avec une date ou une combinaison date-heure spécifique (dans le bon format) pour commencer extraire ce sous-ensemble dans un autre fichier plus petit. Par exemple, si vous savez que le crash s'est produit aujourd'hui un peu après midi alors que votre journal couvre des mois, vous pouvez

  grep '2020-02-17 12:' / chemin / vers / fichier > extrait-log.txt
 

Cela vous donnerait toutes les lignes contenant un horodatage compris entre 12:00:00 et 12:59:59 inclus. Bien sûr, le format exact dépendra du format réel utilisé pour les horodatages.

grep analysera le fichier entier une fois pour trouver toutes les lignes pertinentes, ce qui prendra un peu de temps sur un très gros fichier, mais vous aurez alors un fichier beaucoup plus gérable.

Une alternative peut être d'utiliser dd pour "extraire" une partie du fichier d'origine, en utilisant les décalages et les longueurs trouvés dans less ( Ctrl-G pour obtenir le décalage actuel). dd est un outil très puissant mais peut être très dangereux à utiliser, alors utilisez-le avec prudence (et certainement pas en root ou avec sudo si vous n'êtes pas sûr à 100% de ce que vous faites):

  dd if = / chemin / vers / original / fichier de = fichier_destination.txt bs = 1 skip = <start offset> count = <length>
 

Notez que ce n'est pas très efficace, il vaut mieux utiliser une taille de bloc plus grande ( bs ), idéalement une puissance de 2 telle que 1024, et diviser skip et compte par cette taille de bloc.

Je suis presque sûr qu'il doit y avoir d'autres outils qui font la même chose, même si je dessine un blanc.Je pense que certaines versions de cat peuvent le faire, mais pas celle sur macOS apparemment.

Avec les éditeurs de texte sur disque, le fichier n'est pas entièrement chargé en mémoire - ce que vous voyez sur l'interface utilisateur est un aperçu du contenu que l'éditeur a chargé en mémoire.J'ai utilisé avec succès UltraEdit dans le passé pour effectuer une analyse de fichiers journaux volumineux.Ses outils de recherche basés sur des expressions régulières et ses signets de localisation sont particulièrement utiles.Il charge le fichier rapidement et vous pouvez effectuer des recherches basées sur des expressions régulières.L'URL vous amène à une page de téléchargement où vous pouvez télécharger une version d'essai de 30 jours.Il existe également d'autres éditeurs de texte sur disque.

Depuis quelques années, j'ai installé UltraEdit et ouvert le plus gros fichier que j'avais.C'était un fichier binaire de 64 Go et il s'est ouvert instantanément.Ran une recherche d'un terme et cela a pris environ 90 secondes.J'ai mis en évidence la taille du fichier avec un rectangle rouge en bas à droite.Le mac est un MBP 2018 avec 8 Go de RAM exécutant Mojave.

Essayez Glogg.Il y a une version MacOs sur la page de téléchargement:

https://glogg.bonnefon.org/download.html

Je ne connais pas les fichiers de 80 Go, mais j'ai regularly utilisé (sur Windos) pour ouvrir des fichiers journaux jusqu'à 5 Go, et cela fonctionne très bien sur ceux-ci (l'empreinte mémoire après l'indexation est d'environ 100-150 Mo, et la rechercheest very rapide).

Une remarque cependant - c'est un analyseur en lecture seule, pas un éditeur.

Vous ne le feriez pas

Même un fan de Tolkien ne veut rien de 82,7 Go. Vous ne voulez que certains éléments de cela; vous le saurez quand vous le verrez.

Et même envisager un outil qui analyse l'ensemble du fichier est une perte de temps, littéralement; cela va passer 15 minutes à lire le fichier en supposant 100 Mo / s. Beaucoup plus lent s'il fait une analyse de toute complexité.

Le terminal est votre ami

La bouée de sauvetage ici est que OS X est construit sur Unix. C'était une grande partie de l'achat par Apple de NeXT et du retour de Steve Jobs. Cela signifie que vous pouvez utiliser toute la suite d'outils Unix, qui sont extrêmement bien rodés et très bien pris en charge ici.

Il existe des dizaines de façons de le faire sans perl, mais comme perl est intégré à MacOS et est infiniment extensible, je préfère commencer par là (plutôt que de le faire dans un outil plus simple, je veux améliorer quelque peu la requête, appuyez sur le bouton limites de cet outil, et doivent le recréer dans un autre outil). Donc quelque chose comme ça dans un fichier appelé, dites "xx":

  $ len = -s "filename.log"; # variable devient la longueur du fichier
 open ($ IN, "<", "filename.log");
 chercher ($ IN, $ len - 10_000_000, 0); # perl autorise _ en nombre pour la lisibilité

 while (< $ IN>) {# <> lit une ligne. La variable par défaut est une métavariable $ _
   impression; # sans argument, la valeur par défaut est la métavariable $ _
 }
 

Cela ne lira pas tout le fichier, recherchez simplement l'emplacement spécifié (10 Mo à partir de la fin), puis lisez et imprimez tout jusqu'à la fin. Il l'imprimera simplement à l'écran, donc pour l'envoyer dans le fichier, faites ceci lorsque vous l'appelez:

  perl xx > tailfile.txt
 

Vous avez maintenant un fichier tailfile.txt de 10 Mo que vous pouvez ouvrir avec autre chose.

Il existe des moyens plus simples de faire exactement cela , mais supposons que vous réalisiez "Attendez, je veux faire plus. Je ne veux que des erreurs et des avertissements." Vous changez donc la commande d'impression en

  imprimer si / erreur / i ou / warning / i;# // correspond au texte, la valeur par défaut est $ _
 

Cela aussi peut être accompli dans des outils plus simples si vous passez suffisamment de temps à parcourir les documents.Mais alors, vous décidez que vous devez voir les trois lignes après l'erreur.Juste comme ça ... vous avez dépassé les outils les plus simples, mais c'est trivial en Perl.Vous pouvez continuer à caler Perl pour toujours.Il y a un langage de programmation complet là-dedans.Orienté objet et tout.

Un fichier aussi volumineux est probablement redondant à 99,999999% (littéralement), donc la clé est de supprimer les lignes qui se produisent des millions de fois, avec un certain degré de similitude, et d'examiner ce qui reste.

Sous Linux, il existe un utilitaire appelé petit , conçu pour analyser d'énormes fichiers journaux, qui fait cela. Un exemple d'utilisation est petit --hash /var/log/kern.log . L'utilitaire peut probablement être trouvé ou construit pour Mac.

Il traite chaque ligne du fichier pour supprimer les éléments qui rendent la ligne unique; par exemple, supprimez la date de chaque ligne et remplacez toutes les chaînes de chiffres par un seul caractère #. Chaque ligne générique est ensuite hachée pour devenir une empreinte digitale pour la détection de lignes similaires.

Le résultat est qu'il affiche chaque ligne une seule fois avec un nombre d'occurrences, ce qui réduit considérablement la taille des données. Tout ce qui sort de l'ordinaire est susceptible d'apparaître clairement, et ensuite on peut le rechercher spécifiquement, en utilisant les utilitaires de certaines des autres réponses ici.

Je ne sais pas si cet utilitaire particulier est suffisamment performant pour quelque chose de cette taille. Je parierais que oui, car il a des options pour tracer des graphiques de l'ordre de mois ou d'années d'entrée, et n'aurait pas besoin de stocker grand-chose en plus d'un petit nombre d'empreintes digitales. Dans le pire des cas, vous pouvez écrire la vôtre: pour chaque ligne d'entrée, générialiser en une empreinte digitale, la hacher et l'ajouter à une base de données de hachage + empreinte digitale + compte, indexée par hachage.

EDIT : petit semble utiliser plus de CPU et de mémoire que souhaité, j'ai donc écrit ma propre implémentation simple: https://github.com/curtmcd / hashlog. Il effectue un passage dans le fichier journal; il traite à environ 6,5 s / Go sur mon serveur Ubuntu domestique.

"joe", alias Joe's Own Editor, a été conçu pour ne charger que certaines parties du fichier selon les besoins.Je ne l'ai jamais utilisé sur un fichier aussi volumineux, mais je n'ai jamais rencontré de fichier texte trop volumineux pour qu'il puisse s'ouvrir.

Certainement Hex Fiend.Il ouvre les fichiers SANS utiliser la RAM.Il lit simplement à partir du disque.La performance est absolument incroyable.J'ai déjà examiné des vidages de mots de passe de 500 Go avec.

https://ridiculousfish.com/hexfiend/

Ouvrez le terminal et utilisez vim pour l'ouvrir

  vim filename.txt
 

P / s:

Tapez vim et faites glisser le fichier vers votre terminal.Puis appuyez sur Entrée.

Pour quitter vim (sans modification):

 : q!
 

Je recommanderais d'utiliser Sublime Text.Bien qu'il nécessite une licence, il peut être téléchargé et évalué gratuitement sans limitation de temps ou de fonctionnalité.Cela signifie que vous ou votre entreprise pouvez avoir la chance de l'essayer autant et comme vous le souhaitez.Je l'utilise personnellement pour enquêter sur des journaux de peut-être même 3-4 Go dans la plupart des cas, ou pour des vidages SQL de même 12 Go.Lors de l'ouverture initiale, il parcourt tout le fichier afin d'effectuer une indexation de 1er niveau, etc., mais il est livré avec une barre de progression indiquant la progression du processus dans son ensemble.