Traditionally, Unix has operated by piping between commands ("find | grep | sort | uniq"). I wonder if we are experiencing a shift to command composition being a more common model?

I started thinking about this when I considered the following command line:

chronic mr run git annex get

Unpacking, that uses chronic, which arranges for quiet running of mr (unless it fails, then it shows the full output), which in turn runs git in every repository it knows about, and git is asked to run the git-annex subcommand, which in turn has a "get" subcommand of its own.

So, in other words, this is a cron job that syncs large files in a set of git repos, quietly. You might want to make it run niced also, which adds 3 more commands:

chronic nice ionice -c3 trickle -d100 mr run git annex get

This is the most extreme example I know of (unless you tack in a "sudo"), but there does seem to have been a gradual shift to using more composition, and more subcommands. In git in particular, two-levels of subcommands is not unknown, for example "git remote add". Subcommands, especially as implemented in git (or earlier, in arch), are kind of a special case of command composition that adds a namespace. I'm sure that a count of commands with subcommands would show it exploded in the past 10-12 years. I'll bet a count of composable commands would also show a significant increase.

Anyone have other examples of long compositions of commands?

comment 1

hi Joey,

Many of djb tools (sometimes referred to as 'djbware') use the same concept.

  • (this one can be seem as an extreme one, but it is use ;-)
Comment by cstamas []
comment 2

In OpenVMS, most commands are of the form 'command verb noun' or 'command noun verb'. This history also carries on to a lesser degree in Windows and other derivatives.

However, I think you're confusing two things. We use pipes when we want to transfer data between commands, and composition when: 1. When a single executable provides multiple useful entry points, like a SCCS tool. 2. We want a command to support both an interactive shell and a command-line interface. 3. We want commands to operate on other commands.

I'm not sure whether there's actually been a recent explosion of that on UNIX / Linux or not.

Comment by Adam