It's not a bad exercise. In a Unix class I took, we had to implement an RDBMS using only the traditional Unix software tools. A little later, for work, I had to learn to write highly portable and fairly secure shell scripts.
A few reasons to do exercises like this:
* To understand the Unix software tools and Bourne/etc. shell scripting models. There are good lessons, and also examples of what not to do (or the tradeoffs), which I don't think you'll find anywhere else. (For example, the simple Unix streams model is very powerful, and also often used in very kludgey ways in practice, and the Bourne evaluation model is probably much worse and dangerous than a beginner might think.)
* Knowing how to do things with just shell scripts is great for some kinds of bootstrapping, commands in build tools, or other situations in which you can only assume a shell interpreter and possibly certain command-line tools.
* Handy for configuring your interactive shell to do what you want.
* It's one way to familiarize with parts of a Unix-ish system that you might not normally, especially if you're spending all your time learning your way around huge stacks of tools that obscure the lower-level mechanics.
* You'll appreciate Perl and other languages much more, in some ways.
"After some thinking, I figured it would be hilarious to actually implement a basic version control system on these primitives. In hindsight, it's probably closer to terrifying than hilarious."
Ah, ok.
Also, if you want to experiment with diffs and recreating versions:
I once had to edit a file while logged in on console and where I literally had nothing but the Bourne shell to work with. I eventually figured out a while loop which read a line at the time from the file, echoed it, then read a line from the tty, where typing just return meant to keep the line as is, else use the line I typed, and sent the output to a new file. I then used shell redirection to replace the old file. Maybe I had "cat" too.
That was tedious.
It was circa 1995 on an HP/UX machine that was nothing but an X terminal, but its root disk for some reason only had the minimum of files that it needed to mount everything else via NFS, but somehow all the automounts had become misconfigured.
As I recall anyway.
And here's a network calculator I wrote mostly in awk:
I was thinking of situations like described in the GP, where most external commands would be unavailable. Aside from what was described there, screwing up the shared libc is also common. Where you're left with a functional shell if you were logged in, but no external commands, except for /sbin/ stuff.
The hack with echo mostly works, but will have issues with large files due to limits on arg length.
If I remember correctly, implementing a file history system using shell scripts and the basic UNIX tools was one of the more advanced worked examples in The Unix Programming Environment by Kernighan and Pike.
A few reasons to do exercises like this:
* To understand the Unix software tools and Bourne/etc. shell scripting models. There are good lessons, and also examples of what not to do (or the tradeoffs), which I don't think you'll find anywhere else. (For example, the simple Unix streams model is very powerful, and also often used in very kludgey ways in practice, and the Bourne evaluation model is probably much worse and dangerous than a beginner might think.)
* Knowing how to do things with just shell scripts is great for some kinds of bootstrapping, commands in build tools, or other situations in which you can only assume a shell interpreter and possibly certain command-line tools.
* Handy for configuring your interactive shell to do what you want.
* It's one way to familiarize with parts of a Unix-ish system that you might not normally, especially if you're spending all your time learning your way around huge stacks of tools that obscure the lower-level mechanics.
* You'll appreciate Perl and other languages much more, in some ways.