Question: grepping, awking, sedding, and piping are day-to-day routine of a user of any Unix-like operating system, may it be on the command line or inside a shell script (collectively called *filters* from now on).

At their essence, when working with "standard" Unix CLI programs and shell builtins (collectively called *commands* from now on), filters need a precise expected format for stdin, stdout, and stderr in each filter step in order to work correctly. I call this precise expected format of some command an API of this command in the following.

As someone with web development background, I compare this kind of data collecting and data processing technically with [web scraping](http://en.wikipedia.org/wiki/Web_scraping) - a technique which is very instable whenever there is the slightest change in data presentation.

My question now relates to the stability of Unix command APIs.

1. Do commands in a Unix-like operating systems adhere to a formal standardization with respect to their input and output?
2. Have there been instances in history where updates to some important command caused to break the functionality of some filter that was built using an older version of said command?
3. Have Unix commands matured over time that it is absolutely impossible to change in such a way that some filter could break?
4. In case filters may break from time to time due to changing command APIs, how can I as a developer protect my filters against this problem?

Answer: 
I'll try to answer from my experience.

1. Commands don't really adhere to a formal specification, but they do adhere to a requirement to consume and generate line-oriented text.
2. Yes, of course. Before the GNU utilities became a de facto standard, a lot of vendors would have quirky output, especially with respect to `ps` and `ls`. This caused a lot of pain. Today, only HP delivers super-quirky commands. Historically, the Berkeley Software Distribution (BSD) utilities were a major break with the past. The POSIX specification was a break with the past, but now it's widely accepted.
3. Unix commands have indeed matured over time. It's still not impossible to break some script written for an older version. Think about the recent trend towards UTF-8 as a text file encoding. This change necessitated changing basic utilities like `tr`. In the past, simple text was almost always ASCII (or something close), so uppercase letters formed a numerical range, as did lowercase letters. That's no longer true with UTF-8, so `tr` gets to accept different command line options to specify things like "uppercase" or "alphanumeric".
4. One of the best ways to "ruggedize" your filters is to not depend on particular text layout. For example, don't do `cut -c10-24`, which depends on positions of a line. Use `cut -f2` instead, which would chop out the 2nd, tab-separated field. `awk` breaks any input line into $1, $2, $3... which are white-space separated by default. Depend on higher-level concepts like "fields" rather than lower-level concepts like column position. Also, use regular expressions: `sed` and `awk` can both do things with regular expressions that don't care about some variance in input. Another trick is to process the input into something whose format your filter can be picky about. Use `tr -cs '[a-zA-z0-9]' '[\n]'` to break text into a single word per line, without punctuation. You just don't care what the input text is like in that case.
Scripts do break, some more often than others. The old and famous software tends to stay relatively the same, and often has compatibility flags when it changes anyway.

Scripts written on one system tend to carry on working, but often break another.