OSDev.org

I realize there are already several alternative implementations of programs like GNU's core utilities such as Busybox, Toybox, sbase, core programs from BSD systems, etc. However, I'd still like to code an implementation of some of the basic utilities myself in C for the experience and for ease of debugging. While most operating systems use GNU or some of the other options mentioned, I noticed some of the operating systems listed on the forum go to the trouble of reimplementing these types of utilities from scratch. Would love to compare notes on development with others working on this sort of thing.

Many of the utilities appear to have some type of standardization. There's the POSIX standards. GNU and BSD supply many if not all of the POSIX features and then add their own functionality creating their own standards. Busybox, Toybox and sbase usually provide a subset of the GNU and/or BSD capabilities. I'd personally like enough functionality to make sure scripts used to build programs I need work properly. Beyond that, anyone have any tips on how they decide what features or functionality to put in or leave out? Was there anything you had to watch out for when coding your own utilities? Were there any internationalization issues you had to contend with? Do your utilities work with files in text format (handle CR/LF like with MSDOS/Windows) or strictly in binary format (LF) or with other formats? Are you writing your utilities completely from scratch or are you adapting Open Source versions you've found to work with your operating system?

Anyone care to share more about what they're working on in the area of basic utility programs? Thanks.

Especially sbase and some others don't even go as far as full POSIX conformance, since that is already often bloated. For example, interactive mode in cp/mv/rm. Completely contrary to the entire rest of the applications, suddenly you require terminal input. cat -u is often ignored, which I always find funny.

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.

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.