busybox vi doesn't use ncurses?

[Rob Landley]

On Tuesday 13 June 2006 9:28 pm, Rich Felker wrote:
> On Tue, Jun 13, 2006 at 06:35:43PM -0400, Rob Landley wrote:
> > On Sunday 11 June 2006 1:31 pm, Paul Fox wrote:
> > >  > > We use ansi escape sequences and no curses impl.
> > >  >
> > >  > Do you know an hexadecimal editor that works with busybox? All those
> > >  > I've found need libncurses.
> > >
> > > i'd look at xxd, or hextools (http://freshmeat.net/projects/hextools/),
> > > which are apparently tools that take a hexdump and convert it
> > > back into a binary file.  i've never used either one.  i have a
> > > simple tool called "unod" which undoes the traditional unix "od -c"
> > > format.  if someone knows how to get the busybox hexdump to
> > > create that format, then that might be a very small solution (but
> > > you'd have to work in octal).
> >
> > Good grief, I wrote hex editor for the 1541 disk drive in commodore 64
> > BASIC when I was 12 years old.  Is there really nothing out there that's
> > at least reasonable?
>
> Writing a good hex editor is not difficult but also not at all
> trivial. Keep in mind that you'll likely want to be able to edit HUGE
> files (possibly even bigger than address space) or even whole disk
> volumes,

If you're not worried about supporting insert, mmap().  If you're worried 
about supporting insert, you're limited to sizeof ram.  Yeah, I could work 
around that but I'm not going to.

I load my mbox in vi.  It's hundreds of megabytes.  Wooo.

My approach to implementing this sort of thing has always been do do a 
reasonable job, wait for somebody to complain about scalabity, and figure out 
whether or not I care when they tell me what strange thing they're trying to 
do.  "This is not the tool for that job" has often been a good response to 
some of this stuff.

(Yes, I could trivially make an "offset/length" command line option and have 
the editor work a bit like dd.  But the way you approach me, my immediate 
response is "get this opinionated jerk out of my face".  I'm not quite sure 
why that is, but it gets pretty strong at times.  I don't owe you a hex 
editor.  I was thinking of writing one, but you managed to turn me off to the 
idea.)

> so the hex editor must keep track of changes in memory (in 
> some sort of incremental/patch type structure) and demand-load or mmap
> regions of the file on disk for editing.

You have a knack for getting deeply worked up over purely theoretical issues.  
Do you work in academia?

On a 32-bit system, you can't mmap more than about 3 gigabytes.  (Kernel VMA 
area, remember?)  On a 64 bit system, this is not a practical limitation.  In 
about 3 years, 64 bit systems are going to become really common.

And if you _are_ editing a multigigabyte block device, then supporting 
"insert" isn't really much of a concern, is it?

> All the *nix hex editors I've seen (a friend was looking for a good
> one just a few days ago and we looked all over with no luck) can't
> handle anything but very small files and are generally useless
> compared the stuff I used on DOS ages ago (like norton diskedit).

Then write your own, and stop bothering me about it.  For some reason, I find 
your attitude highly annoying when I'm tired.  I probably shouldn't, but I 
do.

> Rich

Rob
-- 
Never bet against the cheap plastic solution.