CCA Commandline Tools

Virtually everything we target doing can be readily done (and has in the tutorial) with basic gmake usages except proposed splicer-based functionality. This means:

1. bash should be perfectly satisfactory for all but the splicer-based operations.
2. what's left to argue about is the detailed directory layout (which the user should be able to override anyway) and ergonomics of the command line.
3. splicer operations can be done in any implementation language, and we have at least a Ruby prototype to be extended. Personally, I would write the splicer as a C tool using babel, following the prototypes in ruby and java that exist.

The classical stateful unix tools (CVS, SVN, Mozilla, news, ...) all rely on (hidden) directories full of captured state information so the user can work with minimal repetitive typing. In the case of tools supporting multiple databases (SVN, CVS) the trick is always done with an assumption of the working directory being the home of the saved state (.svn/, CVS/) and we should take a lesson from these.

The prototype bash-based system (which has help fully implemented in lieu of documentation) is at


Design basis

1. Any unix command longer than 3 letters is too long. I might ve willing to relax this -Rob (BAA: svn and cvs teach well. If we're going to have 17 'top level' commands instead of just 1, obviously we can go longer).
2. Bash is available everywhere.
3. We should boldly refuse to finish sentences and edit text; those users should get eclipse, instead. elaborate gui's are not our thing - Rob (BAA: it's not just guis; emacs bigots have gone down that road, too, with very elaborate tooling).
4. I'm not willing to force my favorite scripting language (tcl) or Rob's (Ruby) or Boyana's (python) or a gui on anyone. granted, but what if we could run the java versions of any of these?-Rob (BAA: To me there is no significant difference between Java and C (other than portability to classified hpc platforms) for the requirements of this project except the scandalously large MBytes of binary installs one must do before running even hello-world in java.)
5. The command line syntax proposed is entirely independent of the underlying implementation language (bash, c, java, etc) and is thus trivially scriptable from any language that supports a system() call.

I do not like the naming structure. Why have it in the form:

Why not just:

what's the point of the extra, what amounts to a, prefix?


BAA: cct is the least amount of info needed on the commandline to get us the context information we need without repeating ourselves at some point. My previous proposals on this topic have all ended in excessive wordiness, repetition of already known info, or a requirement for dropping the user into a ruby/python/tcl shell until they're done with 'ccaisms'. The prefix is short, and like cvs, svn, etc, it lets us get into our own command-line language independent of what the user's shell is. This lets us do things like

Where Known Babel Types Become Subcommands, essentially.
Rob: I find this argument to be compelling. If I understand it correctly, we are using the project context so that cct already understands all it needs to know about the component MyComponent

where we see MyComponent is a project specific subcommand that I, the cct tool provider, didn't need to know apriori. The usual subcomands of something like svn don't conflict with anything else in the user's PATH because they are never at the unix shell level.

Python, ruby, tcl similarly allow us to define new commands ad-hoc, and to make the new commands appear on the path (in the working script environment) without changing the PATH in the user's shell. It's going to be hard to beat the value of the lessons learned by the whole unix community about how the command lines look in tools that support multiple simultaneous projects/packages running in arbitrary shells.

Any choice except sh/csh/bash is going to immediately allow evaluators of the new tools to say oh, it depends on X; I don't like X and version Y of X doesn't come with my OS yet; we should care about eliminating these excuses for using our tools.