[BusyBox] Re: busybox-cvs Digest, Vol 29, Issue 4
pgf at brightstareng.com
Tue Aug 2 13:29:31 UTC 2005
> What for you commiting all patches successively?
hi vodz --
is there a different ordering that you'd prefer? :-)
perhaps you didn't see the couple of messages i sent out asking
for feedback before i began committing them these bugs?
busybox development was stalled for many months last year.
users were still contributing fixes and features, but for a
variety of reasons (many unknown to me) the contributions weren't
being applied to the source base -- they were accumulating in the
archives and the bug system. rob recently got a whole bunch
of energy (and a new laptop, i think :-), and started going
through the backlog of patches sent to the mailing list, with the
intention of generating 1.0.1 and 1.1 releases. i offered to do
some of the same for the bugs in the bug system.
> > + /* there is no way for bb_getopt_ulflags() to
> > + * return us the argument string for long options
> > + * which don't have a short option equivalent.
> Its False. Have way: using non printable short option.
yes, you and i talked about this before, and i remember your
solution. i consider it unacceptable to write programs which
have hidden unexpected features on the command line. if the
option processing api changes, i'm happy to change the ls code to
> > commiting:
> > 0000073: Add option to inetd applet to run in foreground
> > this option was already there for uclinux -- this just exposes
> > it in the normal case as well.
> Idioten patch. Absolytelly unecessary.
> Inetd make daemons itself, and foreground usage is hack special
> uclibc ONLY.
no, foreground isn't a hack -- it's an inexpensive feature, which
some people can make use of. this wasn't my patch, but i may
start using this option sometime soon. we have a product that
uses inetd, but only sometimes. we turn it on when we need it,
and off when we don't. if inetd had had this option at the time,
we might have used minit/msvc to control it, as we do for most of
our other system services. because of the specific use case
(when we do start inetd, we don't really need it to die until a
reboot), we used another start mechanism. if this option had
been there, we would likely have "leveraged our existing
infrastructure", so to speak.
thanks for keeping an eye on things!
paul fox, pgf at brightstareng.com
More information about the busybox