Riwux core +============+ The rcore project aims to provide a minimal but complete commandline environment containing utilities found on most UNIX(-like) systems. It's goal is to be simple, portable and compliant while still being pleasant to use. Features and extensions are chosen carefully and only implemented if they are either (very) common or provide real value to the user. Modules +=========+ rcore is split into several different subdirectories (i.e modules), each dedicated to a specific standard or group of utilities. This adds the possibility to exclude certain tools (e.g. linux/ on BSD systems) or only select a small subset to be replaced on an already existing system. posix/ -- POSIX.1-2017 utilities more/ -- common non-standard utilities linux/ -- non-portable Linux specific utilities Build +=======+ rcore requires a compiler that implements ISO C99, a libc that conforms to POSIX.1-2008 and ISO C99 as well as a make(1) implementation that is POSIX.1-2008 compliant and supports <slash>'es in target names. To build rcore, follow these instructions: $ make # build the whole project $ make all # same as above $ make install # install utilities $ make uninstall # uninstall utilities $ make clean # remove all binaries and build leftovers $ make posix # only build POSIX utilities $ make more # only build non-standard / more utilities $ make linux # only build Linux specific utilities $ make lib # only build libraries (in lib/) $ make posix/src/cat # only build utility specified by the path (i.e. cat). # It might be necessary to build lib/ first In case you want to customize your build process, change the corresponding values in config.mak or directly on the commandline. Supported compilers: clang $ make CC=clang gcc $ make CC=gcc tcc $ make CC=tcc cproc $ make CC=cproc pcc $ make LDFLAGS='-L lib/libutil -lutil' CC=pcc Conventions +=============+ * Error messages: It's important that error messages are consistent across all utilities since they form the base of a system and should feel coherent. The format is simple but does not hide any information. It should be possible to look at an error message and immediately know what happened. The format is specified as follows: <utility> [: <function> ['<argument>']] [: <message>]\n utility : The name of the program. function : The function that reports the error. argument : The argument the function operates on (if any) message : optional useful information (e.g. errno-string) * Function names: Function names that are part of a library (i.e shared accross all tools) and have the potential to exit(3) the program are prefixed with 'x_'. Those functions local to a utility don't (have to) follow this convention. * Options: Mutually exclusive options (e.g. [-a | -b]) can be specified together without resulting in an error. The last option specified is used/active while the options prior are ignored and have no effect. util -a -b -a -b -a -c In this example '-a' will be used by the program since it is the last out of the mutually exclusive options 'a' and 'b'. The normal option 'c' will be active regardless since it has no relationship with the other options. Long options are not implemented since they are non-standard and don't provide much value. Most of the time they just provide another, longer name for an already existing option. They complicate and confuse a program without adding functionality or anything useful.