[BusyBox] Changing the way help is displayed...

[Vladimir N. Oleynik]

Manuel,

> The important thing to note is that the usage messages have been decoupled
> from the C code; no more char *'s for each different message.

The main thing not in to fall in an extreme measure and to use available
decisions. 
The current condition if to tell softly, very inconsistent. On the one hand, for
test compilation it is necessary to insert lines for compile with libbb:

const char *applet_name = "debug stuff usage";
const char *memory_exhausted = "Memory exhausted";

(First line declared in busybox.c, second - messages.c (brrr))
For testing usage() function, completely temporarily it is necessary to
substitute a file
usage.h.

With it it is necessary to make something...

My ideas:
1) messages.c delete, locale trasnlations make with bindtextdomain()
2) usage():
2a) restore previous variant with string pointer in applets struct
2b) move to separate/archive file(s)
2c) and in Config.h put options for generate 2a or/and 2b variants in any
combination
for all applets.

> In fact, after mulling things over, I really think the whole applet code
> framework should be reworked.  For instance, the fact that the
> applets must be in sorted order in applets.h makes it difficult for unofficial
> applets in the proposed contrib directory to not interfere with each other,
> either in applets.h or config.h.

O, my old prayers.

> One thought that occured to me is to move away from using config.h and cpp to
> handle configuration.   Here's one possible scheme:
> 
> 1) Associated with each applet would be 4 files:
>     <appletname>.h - prototypes/extern defs for anything exported globally
>     <appletname>.c   - the applet code itself
>     <appletname>.usage  - the usage message text (in some easily processed form)
>     <appletname>.cfg   - information on applet features and dependencies

Here can be arise desire to simplify some functions in the common library if not
some 
set of the utilities demanding more universal function (additional options,
variable vs
constants etc.) is used... ;-)

Old example special for you mind: process_escape()
a) current, usage in `tr', but in `sh' full erroneous using
b) process \E \xhh for bash-syntax $'C-string'
c) process \W \w \! ... for bash prompt
z) process \: for termcap parser ;-)))
 
> Please note that I'm just throwing these ideas out for discussion.  I'm not in
> a position right now to really work on this.  

It would be possible to begin with association with tinylogin then these
problems would be
more brightly visible. Such did not happen with netkit as did not demand basic
alterations
of structure of the project. ;-)

> What time I've had lately has
> beed devoted to getting the uClibc gcc wrapper sorted out and getting a
> uClibc-specific dynamic linker working (at least or i386).  I'm also about 90%
> finished with consolidating Dan Bernstein's code for djbdns, qmail,
> daemontools, uscpi, etc. into one tree which uses shared libs and builds
> against uClibc.  (The only real uClibc problem was the lack of libresolv, but I
> modified qmail's dns.c file to use the djbdns routines instead.)  I've also got
> Vladimir's latest uClibc locale patches to look at that I haven't gotten too in
> over a week (sorry vodz)

Not a trouble. Me so have given the basic a full-time job, that I have
practically deserted
also this maillist ;-)


--w
vodz