8

I've got a fairly simple problem here: I have a piece of text which is one giant big line (~150,000 characters). No line breaks, and it's a fixed-length flat file (i.e. it was produced by a COBOL program), so introducing line breaks is not only awkward, it's actively unhelpful if I'm trying to make changes to the file.

Most text editors struggle with a single line that big (less doesn't like it, Gedit doesn't like it, nano doesn't like it, I've heard vim doesn't like it, etc), though they do work.

Does anyone have any suggestions for an editor that would be better suited to the data I'm working with? It's only a single line, but it still causes more problems than a 1GiB+ text file with normal-length lines would...

Would be even better if it would work with EBCDIC and not barf when it encounters null bytes, or mangle them when writing back out (some fields are binary-encoded decimals).

Please note, this isn't about files that are big in terms of raw size - the file contains only a single line - but about the fact that most editors aren't optimized to cope with very long lines.

Improve this question
9
  • 1
    @smc see his last paragraph where he says this isn't about big in terms of raw size – barlop Jul 7 '14 at 12:19
  • Perhaps you could show a screenshot of how the obvious things to try - vim/gvim or emacs fails (if they do!)? – barlop Jul 7 '14 at 12:20
  • @barlop (+1), you are correct, I have removed my comment – Art Gertner Jul 7 '14 at 12:22
  • @barlop They don't fail in the sense of not working, they just tend to be really slow. I've also pasted long lines into Eclipse once or twice, and that was a really bad idea - completely locked it up, actually had to kill the process. – ipsi Jul 7 '14 at 12:40
  • 2
    Have you just tried vim? You heard it's going to be slow, but why don't you just give it a try? It won't cost you much. – Dakatine Jul 7 '14 at 12:52
5

I think a file like the way you are describing is, for practical purposes, acting like a binary file and you should treat it as such.

You could attack it with a hex editor, but that doesn't help you with the EBCIDC part.

If you have to do a lot of editing on this file and are intimately familiar with its fixed-length record format, it may be worth your time to whip up something in Perl or another language (I suggest Perl because it's old and would very likely have modules that convert UTF-8, etc. to EBCIDC), that would work with this file's specific format.

Improve this answer
0
6

I actually just tried vim on a file with a single line of 150000 characters and it ran smooth as silk.

So I guess you should really give it a go, if you didn't just because you heard vim doesn't like such kind of files.

Here's how I got my file:

seq 150000 | while read num; do echo -n "b" ; done > megaline.txt
Improve this answer
2
  • 1
    I've seen Vim handle large files well and I've seen Vim handle large files poorly. It very much depends on the configuration. (My main configuration handles long lines poorly, but it doesn't come up often so I haven't investigated lately) – RJHunter Jul 7 '14 at 14:02
  • 4
    Turn syntax highlighting off if it runs slowly. – LawrenceC Jul 7 '14 at 16:12
3

I tried the same method as Dakatine with my emacs install and it worked fine. No hangups, nothing. If you're editing plain text (i.e. not doing any of the kind of analysis that a mode for a programming language requires, in text-mode), it's going to be really, really hard to lock up emacs. The behavior that you're seeing with Eclipse is probably a reflection of the fact that Eclipse is trying to do some sort of analysis on the text as it renders it -- ditto for Gedit. I also can't reproduce your issue with less -- it comes out fine for me.

Improve this answer
2
  • Plus you've got things like CobolMode and Ebcidic Table that might help. – jwd630 Jul 7 '14 at 17:44
  • I'm having an issue in emacs at the end of the file when it's trying to match up braces. (It's a JSON file, but I'm using text-mode.) – Jayen Mar 25 '16 at 6:08
3

Give it a try: JEdit - A programmer editor

It's got some advanced buffering features, and highly optimized I/O, but takes a while to start up (due to JVM). I've been using it to view & edit over 1GiB files without any trouble - at least on Debian. I cannot guarantee it will behave as good on windows though... :)

Improve this answer
1
  • Although I can't find High DPI support yet, I can attest it works on long lines where gedit crashed. – WinEunuuchs2Unix Aug 26 '19 at 23:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.