Contributing

Contributing

Currently ccsh is still under construction. Bugs may occur, you may find unimplemented features. Feel free to open an issue, or fix them, fork the project on GitHub and submit pull requests. It is really lightweight, the scripting library currently (April 2017) consists of ~2500 lines of undocumented code.

However, as Components page describes, coding wrappers needs help. If your code happens to call a program with different parameters, you may find it easier to implement a wrapper yourself for that. If that is the case, please open a pull request for that. Our requirements for a wrapper are the following:

• All switches of a program should be implemented which are provided by its latest version.
• Wrapper classes should consist of a class (e.g. ls_t) which is derived from command_native and a typedef: using ls = command_holder<ls_t>;.
• If the program uses the GNU convention – program [options]... [--] [files]..., with options starting with dash –, the class should be derived from ccsh::wrappers::options_paths which provides convenience functions and macros for specifying arguments.
• Methods should be duplicated, have a ref-qualified and a refref-qualified version, and return *this as command_holder<ls_t> as ref or refref. This makes chaining possible.
• Classes must be header-only, thus static class members should be avoided. We suggest replacing them with function static variables, or if inevitable, making the class a "fake template", like ls_t.

Documentation of options_paths, its convenience functions and macros are to be done. See nl.hpp for a simpler example, and ls.hpp for advanced tricks. Looking at their options and C++ representation, it should be easy to figure out what the macros mean.