have any suggestions how they plan to go about it, and to minimize conflicts
between your work and theirs. But otherwise, all of these are fair game.
-Rob Landley suggested these:
- Add a libbb/platform.c
- Implement fdprintf() for platforms that haven't got one.
- Implement bb_realpath() that can handle NULL on non-glibc.
- Cleanup bb_asprintf()
+Rob Landley suggested this:
+ Implement bb_realpath() that can handle NULL on non-glibc.
Remove obsolete _() wrapper crud for internationalization we don't do.
Figure out where we need utf8 support, and add it.
sh
- The command shell situation is a big mess. We have three different
+ The command shell situation is a mess. We have two different
shells that don't really share any code, and the "standalone shell" doesn't
work all that well (especially not in a chroot environment), due to apps not
being reentrant.
- lash is phased out. hush can be configured down to be nearly as small,
- but less buggy :)
- init
- General cleanup (should use ENABLE_FEATURE_INIT_SYSLOG).
+
Do a SUSv3 audit
Look at the full Single Unix Specification version 3 (available online at
"http://www.opengroup.org/onlinepubs/009695399/nfindex.html") and
Even better would be some kind of automated compliance test harness that
exercises each command line option and the various corner cases.
+
Internationalization
How much internationalization should we do?
---
possible code duplication ingroup() and is_a_group_member()
---
- Move __get_hz() to a better place and (re)use it in route.c, ash.c, msh.c
+ Move __get_hz() to a better place and (re)use it in route.c, ash.c
---
See grep -r strtod
Alot of duplication that wants cleanup.
in_ether duplicated in network/{interface,ifconfig}.c
---
unify progress_meter. wget, flash_eraseall, pipe_progress, fbsplash, setfiles.
-
+---
+ support start-stop-daemon -d <chdir-path>
Code cleanup:
* even more support for statistics: mpstat, iostat, powertop....
+
+Unicode work needed:
+
+Unicode support uses libc multibyte functions if LOCALE_SUPPORT is on
+(in this case, the code will also support many more encodings),
+or uses a limited subset of re-implemented multibyte functions
+which only understand "one byte == one char" and unicode.
+This is useful if you build against uclibc with locale support disabled.
+
+Unicode-dependent applets must call check_unicode_in_env() when they
+begin executing.
+
+Applet code may conditionalize on FEATURE_ASSUME_UNICODE
+in order to use more efficient code if unicode support is not requested.
+
+Available functions (if you need more, implement them in libbb/unicode.c
+so that they work without LOCALE_SUPPORT too):
+
+int bb_mbstrlen(str) - multibyte-aware strlen
+size_t mbstowcs(wdest, src, n)
+size_t wcstombs(dest, wsrc, n)
+size_t wcrtomb(str, wc, wstate)
+int iswspace(wc)
+int iswalnum(wc)
+int iswpunct(wc)
+
+Applets which only need to align columns on screen correctly:
+
+ls - already done, use source as an example
+df
+dumpleases
+lsmod
+
+Applets which need to account for Unicode chars
+while processing the output:
+
+[un]expand
+fold
+man
+watch
+cut (-b and -c are currently the same, needs fixing)
+
+These applets need to ensure that unicode input
+is handled correctly (say, <unicode><backspace> sequence):
+
+getty, login
+rm -i
+unzip (overwrite prompt)
+
+Viewers/editors are more difficult (many cases to get right).
+libbb/lineedit.c is an example how to do it:
+
+less, most, ed, vi
+awk
+[ef]grep
+sed
+
+Probably needs some specialized work:
+
+loadkeys