We've got fuser, fix some typos, and move Vodz's comment about UTF8 into

a new "internationalization" section, with some related concerns.
This commit is contained in:
Rob Landley 2005-10-31 23:52:02 +00:00
parent c63fe9137f
commit dbc608b568

32
TODO
View File

@ -11,19 +11,14 @@ sh
work all that well (especially not in a chroot environment), due to apps not 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 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 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... Note: Rob Landley (rob@landley.net) is working on this one, but very slowly...
Support unicode for cmdedit.
--- ---
diff diff
We should have a diff -u command. We have patch, we should have diff We should have a diff -u command. We have patch, we should have diff
(we only need to support unified diffs though). (we only need to support unified diffs though).
--- ---
fuser
Would be nice. The basic susv3 options, plus fuser -k.
---
patch patch
Should have simple fuzz factor support to apply patches at an offset which Should have simple fuzz factor support to apply patches at an offset which
shouldn't take up too much space. 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 Even better would be some kind of automated compliance test harness that
exercises each command line option and the various corner cases. 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 Unify archivers
Lots of archivers have the same general infrastructure. The directory Lots of archivers have the same general infrastructure. The directory
traversal code should be factored out, and the guts of each archiver could traversal code should be factored out, and the guts of each archiver could