From dbc608b5687ebe1b828f921c70573280d6c3e313 Mon Sep 17 00:00:00 2001 From: Rob Landley Date: Mon, 31 Oct 2005 23:52:02 +0000 Subject: We've got fuser, fix some typos, and move Vodz's comment about UTF8 into a new "internationalization" section, with some related concerns. --- TODO | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index d179529e8..727fbbadf 100644 --- a/TODO +++ b/TODO @@ -11,19 +11,14 @@ sh work all that well (especially not in a chroot environment), due to apps not being reentrant. Unifying the various shells and figuring out a configurable way of adding the minimal set of bash features a given script uses is a big - job, but it be a big improvement. + job, but it would be a big improvement. Note: Rob Landley (rob@landley.net) is working on this one, but very slowly... - - Support unicode for cmdedit. --- diff We should have a diff -u command. We have patch, we should have diff (we only need to support unified diffs though). --- -fuser - Would be nice. The basic susv3 options, plus fuser -k. ---- patch Should have simple fuzz factor support to apply patches at an offset which shouldn't take up too much space. @@ -51,7 +46,30 @@ Do a SUSv3 audit 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? + + The low hanging fruit is UTF-8 character set support. We should do this. + (Vodz pointed out the shell's cmdedit as needing work here. What else?) + + We also have lots of hardwired english text messages. Consolidating this + into some kind of message table not only makes translation easier, but + also allows us to consolidate redundant (or close) strings. + + We probably don't want to be bloated with locale support. (Not unless we can + cleanly export it from our underlying C library without having to concern + ourselves with it directly. Perhaps a few specific things like a config + option for "date" are low hanging fruit here?) + + What level should things happen at? How much do we care about + internationalizing the text console when X11 and xterms are so much better + at it? (There's some infrastructure here we don't implement: The + "unicode_start" and "unicode_stop" shell scripts need "vt-is-UTF8" and a + --unicode option to loadkeys. That implies a real loadkeys/dumpkeys + implementation to replace loadkmap/dumpkmap. Plus messing with console font + loading. Is it worth it, or do we just say "use X"?) +--- Unify archivers Lots of archivers have the same general infrastructure. The directory traversal code should be factored out, and the guts of each archiver could -- cgit v1.2.3