nullplan wrote:
As far as making sure all scripts work as intended, you pretty much need the full GNU set for this, since so many script authors don't pay attention to the standards, or don't want to use them for being too limited.
Internationalization: My stance is to make everything in English first and maybe, maybe, internationalize later. I want the functionality out of the way first. If I do add internationalization, it is going to be with gettext() or similar.
Text files are handled as per UNIX standard (don't see why we should act as if our text files are dumps from a teletype. I have enough CR/LF issues in the terminal driver!) And yes, I'll add my own tools. Once the kernel is taken care of, writing a cp should be simple enough. dd will be a bit of a challenge, though.
Thanks for the response.
Since I'm using a limited set of programs, I may try to get just enough functionality similar to GNU that they build without having to use the standard GNU coreutils. I've been writing some build scripts to work with CDetect and gnu make instead of the full GNU autotools anyway.
With regards to utility programs and internationalization, I was thinking about filenames using internationalized characters or tools like tr that may need to deal with a UTF-8 character instead of a character from the 'C' locale. sbase added UTF-8 support for tools likes tr. gettext does seem to handle most of the internationalization concerns for standard applications. Also, was thinking of having extra directories if someone wants to translate help files. The tools that display the help files can point to the proper directory based on a setting like the LANG environment variable.
It's great that you're writing your own tools. Would be interested to hear how creating your own version of dd works out and what challenges you encounter.