[BusyBox] bug#1117: Correct my stty in recovery_mode

[Mark Whitley]

A few belated replies.

On Sun, Mar 04, 2001 at 03:08:00PM +0300, Vladimir N. Oleynik wrote:

[re: please seperate whitespace formatting patches from bugfix patches]

>  The basic problem was that the utility was placed in CVS in the changed kind on
> a subject whitespace/formatting. As it was carried out with use programm some
> moments have turned out very badly for reading by the mans.
> Any spaces began to have the majority of lines of comments ;)
> I can not work above a problem when viewing of the text of the program of me
> irritates.

I understand what you mean here. Sometimes I have difficulty reading a hunk of
code if it's badly formatted.

Here's a suggestion: do all the whitespace formatting that you need to do to
make the code readable. Stop here and make a diff (stty-format.diff). Then go
back and do the bugfix work. After you're done, make another diff
(stty-bugfix.diff). Send me both and tell me what order to apply them. That
would work great for me.

> See addition example: my cmdedit.c in CVS lines 1010-1013. Cursedly :(

You mean this?

    110 
    111 
    112 struct history {
    113     char *s;
    114     struct history *p;
    115     struct history *n;
    116 };
    117 

This is cmdedit.c from CVS. What's the problem? I don't understand why you
would curse this.


> So yours changes without consultation of the author real substantiations have my
> discontent under themselves.  

This is a collaborative effort. People make changes to the stuff I write, too,
sometimes without consultation.  It happens. By and large, though, changes
that get in are for the better (we hope). If there's a problem with a change
somebody else made, you're welcome to mention it. If there isn't a problem,
try not to let it bother you.


> >  - If you need to keep your test program at the bottom (the one in the #ifdef
> >    TEST block), that's fine, but if you don't need it, I would prefer that it
> >    be removed.
> 
>  I think, it is time to make with it something. 
> It is the basic theme why I have taken out in general maillist.  

[snipped: why it's difficult to make a test program for a single applet in Busybox]

Here's another approach you could try that doesn't involve using any #define
TEST constructs and eliminates the need to re-define functions used in
utility.c: Comment out of Config.h everything except the applet you want to
test and then compile it (this is what the multibuild.pl script does). You'll
end up with a busybox that has one (and only one) applet in it that you can
test to your heart's content.


> 3) I do not like idea with messages.c. For example we have good idea in
> glibc for internacional translation: bindtextdomain(). We can emulate this.

This is a seperate issue but one worth consideration. We haven't spent too
much effort on things like internationalization because there have been bigger
issues to deal with. Perhaps it's time to give i18n a little more attention,
and bindtextdomain() is certainly one approach that could be used. If you
could show us some code that implements this, that would be even more helpful.


> 4) The new patch to (show_)usage() is made in view of strong optimization on 
> the size.  ( Remember old dispute about bsearch? ;)) ) 
> Well. But let's make an opportunity of everyone applet to have an opportunity to
> comprise text of the "Usage: bla-bla", and file for all applet usage_msgs 
> to generate with programm.

I'm afraid I don't follow what you're saying here. Are you proposing moving
usage messages into messages.c? Are you proposing moving usage messages back
into the applet.c files and have the usage.h file auto-generated? I don't
quite understand what you're saying.



Mark Whitley
markw at lineo.com