How often have you used a UI like this?
| 1. List files |
| 2. Show the current time |
| 3. Show Top |
| 4. Quit |
Enter your selection:
Even if you are a banker, travel agent or a medical doctor I would argue never. These groups are unfortunate enough to still have to use arcane command line interfaces to do unspeakably complex things like recording last week’s hours or reserve a ticket to your home town. But none of these systems are razor thin wrappers for simple shell tools – they are that way because they are really hard to replace. And more importantly, no employer is ever going to ask anyone to make a menu based command line UI for their shell script. It just doesn’t happen anymore. It is not a valuable skill. ASCII art is recreation, not work. So the time spent fiddling with
read is wasted, and could be put to better use.
There are many generally applicable skills you can teach shell newbies:
- The Unix philosophy: writing programs that do one thing, that work with other programs, and that handle text streams. An hour of cobbling together a pipeline of
cut and a light sprinkling of
sed can save days or weeks of data processing which might take a week to write in Python or six months in a spreadsheet.
- On the flip side, they should know the limitations of the shell. Why
while read is several orders of magnitude slower than other language equivalents. Why writing secure shell scripts is basically impossible. Or why big shell scripts are a maintenance nightmare compared to other languages.
- Which tools are available to do what. There are so many useful tools you could probably spend a week full time just touching briefly on each of them. Check out for example BusyBox for a set of generally available tools.
- Where to look for answers and how to ask good questions.
Now that computers are firmly in the hands of casual users, is there some way to teach them how to use the command line without throwing them head first into grep? Of course, anyone with the time and inclination (and someone to contact when they get stuck) can learn to use the shell. Also, of course, there’s an entire spectrum from those who would never touch a mouse to those who would never touch the keyboard if they could avoid it, so there must be room for shifting the bar to entry.
A modest suggestion is to, when possible, show users what is going on behind the scenes to give them an idea of how tools interact and work. Some software like TortoiseSVN, Emacs and Hugin already do this, but those are mostly expert level tools, and I guess rarely used by anyone reluctant to push the mouse into the farther recesses of the desk. Also, they show a ton of output with not much information about what to do to reproduce it. Since the user is not typing the commands herself, she won’t know which line in the output is the command and which are the output without a lot of work (or previous knowledge). So another very useful feature would be to emphasize the commands and tone down the output.
What else could be done?
Did you know that even the vCards listed in the official RFC are not valid? It clearly says
The vCard object MUST contain the FN, N and VERSION types. Still, the example vCards are both clearly missing the N type. As somebody else remarked, releasing a format spec without some reference validator is bound to result in all sorts of invalid implementations.
After searching for a vCard validator without success, I’ve therefore started my own vCard module in Python. It tries to create an object with all the information from a vCard string, and returns what I hope are useful error and warning messages if there’s anything wrong.
Update: Added file validation – Now you can validate files with several vCards from the command line.
Install / upgrade:
sudo pip install --upgrade vcard
Validate vCard files: