Only covering 1) of your question.
Naturally APIs can always change at the will of their creators, and thusly break dependent software, in any language. That said, the great idea of the Unix tools' I/O "APIs" is that there is practically none (maybe 0x0a
as line end). A good script filters data with the Unix tools instead of creating it. That means that your script may break because the input or output spec changed, but not because the I/O format (again, there isn't really one) of the individual tools used in the script changed (because something that does not really exist can't really change).
Going through a list of basic tools there are few that I would also attribute producer, as opposed to only filter:
- wc - print number of bytes, words, lines -- very simple format, thusly absolutely unlikely to change, and furthermore not very likely to be used in a script.
- diff - there have evolved different output formats but I haven't heard of any problems. Also not normally used without supervision.
- date - Now here we really have to take care what we produce, especially regarding the system locale. But otherwise the output format is RFC'ed given you don't exactly specify it yourself.
- cal - let's not talk about it, I know that the output format does differ very much across systems.
- ls, who, w, last - I can't help if you want to parse ls, it just wasn't meant to be. Also, who, w, last, are more interactive listers; If you use them in a script you have to take care what you do.
- time was pointed out in another post. But yeah, it's the same as with ls. More for interactive/local use. And the bash builtin is very different from GNU version, and GNU version has had unfixed bugs for many years. Just don't rely on it.
Here are tools that expect a particular input format more specific than being a byte stream:
- bc, dc -- calculators. Already on the more hackish side of things (really, I don't use them in scripts), and presumably very stable I/O formats.
There's another area with a much higher risk of breakage, namely command-line interface. Most tools have differing features both across systems and across the timeline. Examples are
- All tools using regex -- regex can change meaning based on system locale (for example LC_COLLATE) and there are many subtleties and pecularities across regex implementations.
- Simply don't use fancy switches. You can easily use
man 1p find
for example, to read the POSIX find manpage instead of the system manpage. On my system, I need manpages-posix installed.
And even when using such switches, normally there errors won't be subtly introduced and poison your data. Most programs will simply refuse to work with an unknown switch.
To conclude, I would say that shell has actually the potential of being one of the most portable languages (it's portable when you script portably). Compare to your favorite scripting languages where subtle errors occur, or your favorite compiled program which will cede to compile.
Additionally, at the rare places where breakage may occur because of incompatibilities, it probably would not because of time induced, but because of diversity across the different systems (meaning if it works for you, it did so 20 years before and will in 20 years, too). That is a corollary of the tools' simplicity.