here is setterm and a gratituos question

[Rob Landley]

On Sunday 04 September 2005 14:56, Lord Sidiuz wrote:
> >With a lookup table, we organize the suckers and make sure there's one
> > copy of them ourselves.  And since we have to move it out to a seperate
> > file for translation purposes anyway, a lookup table is easy to do.  (If
> > all elsefails it can be built by a script...)
> >
> >Rob
>
> I don't know what is a lookup table,

Well, really simply:

#define LOOKUP_STRING(x)  bb_translatable_strings[x]
const char *bb_translatable_strings[] = {
 "My hovercraft is full of eels\n",
#define STR_HOVERCRAFT LOOKUP_STRING(0)
 "I vill not buy this tobacconist, eet is scratched.\n",
#define STR_TOBACCONIST LOOKUP_STRING(1)
 "etc..."
}

There's probably a better way to do that, but you get the idea.

> if this takes cpu time I wont 
> like it, i prefer
> to have a few duplacated strings, but I now that busybox is developed
> with sized in mind, not optimizacion.

Optimization is kept in mind, but size comes first.

We care about binary size, run-time memory usage, speed, and complexity.  The 
order of the last three varies from time to time and from developer to 
developer, but the one thing we agree on is that binary size comes first.

Comments on the patch:

What's a "cartel"?  The config help doesn't say.  Is this a command you run?  
Ah, I see it in the code.  Hmmm...  possibly a better approach would be to 
use CONFIG_FEATURE_VERBOSE_USAGE for this?

The option parsing is likely to get completely rewritten, but just a hint: by 
"wich_one" do you mean "which_option"?  If so, it helps to say.  (A reader of 
the function goes "one what"?  It helps to have self-describing code...)

If your setterm.h file isn't #included from anywhere other than that one .c 
file, then why not just have that be in the .c file?  Um, hang on: it's never 
included from anywhere.  And it just #defines a lot of constants that you 
never actually use...

Your changes to ls are pretty clumsy.  The char * can be defined right after 
if(show_color) {, and the last line of your #if cae is the same as the entire 
body of your #else case.  (And that's not even getting into the if(ENABLE_) 
infrastructure it seems I'm still debugging...)

So all this does is save an ansi escape sequence in a variable?

Rob.

P.S.  Wow, now I feel old.  15 years ago back under DOS I wrote a direct 
screen write routine that did full ansi interpretation (I found a copy of the 
spec according to DOS on a bulletin board somewhere, this is before I got on 
the internet).  You fed it a string and it kept track of the cursor position 
with variables, scrolled the screen with memmove when necessary, did bios 
calls to move the vga card's cursor, etc.  It was something like 100 times 
faster than the relevant bios writing routines, and allowed me to keep 
multiple screens in expanded memory and show 2 lines of each screen (this was 
part of a multitasker I'd written); the line the cursor was on and the one 
above, it, unless the cursor wasn't that many lines from the top of the 
screen, of course...

I remember the first time I moved this code from one program to another, and 
forgot to initialize the pointer to screen memory.  The compiler happily 
zeroed out the global variables, so my first test string I wrote to the thing 
scrolled the start of memory, which under DOS contains the interrupt vectors 
for all the hardware and software interrupts (and remember, all dos and bios 
system calls are made via software interrupts...)  One of the interrupts that 
came in in the fractin of a second before the machine rebooted (timer?  
serial?  disk?  keyboard?  One of the dos or bios calls the program made?  
Who knows) overwrote the CMOS's persistent memory that stored things like 
"number of wait states in the ram", and the machine did the slowest reboot I 
had ever seen.  (Counting up memory took several minutes.  The machine had 2 
megabytes.  Apparently, the cmos believed that the ram needed 31 wait states 
to access, and was acting accordingly...)

Those were the days...