Making a good Unix glue language
The problem with a search for alternatives to the Bourne shell is that the Bourne shell is still one of the best Unix programming languages. Or perhaps it would be clearer to call it a 'Unix glue language', a language for connecting existing programs together.
You might sensibly ask what the problems are with things like Perl and Python as Unix glue languages, and my answer would be that they make it too hard to interact with external programs. This is important, because the way you write small programs fast on Unix is to take advantage of as many existing programs as possible. Perl and Python are great if you want to implement everything yourself, and sometimes this is the right answer, but not so great if you want to hastily bang something together.
There's several things that I think make for good interaction with programs:
- make it easy to get results from programs in useful forms. The
Bourne shell is only close on this, since it doesn't easily let
you pick out individual words from multi-word output.
(This probably implies that the language is nearly typeless, at least for output from programs.)
- let you run code in the middle of a pipeline of commands. This is
the killer feature for fully participating in pipelines, instead
of just running them (as Perl and Python do).
(For bonus points, the code should be able to change the global state of the program instead of just running in a sub-process.)
- have built-in, easy to use features for modifying output, since a lot
of the time programs don't output exactly what you want so you need
to transform it a bit (which is what a lot of what
awkget used for, usually in hard to follow ways).
(Of course, a good Unix glue language should still have all the attributes of a good programming language, many of which the Bourne shell lacks. You certainly ought to be able to write normal code without using external programs at all.)
The risks of forcing frequent password changes
People can talk about the risks of not changing passwords at the drop of a hat, but they rarely talk about the risks of forcing people to go through frequent password changes. This matters a lot, because there are significant risks.
(And when people do acknowledge the risks, often it is to decry or mock the 'bad habits' that people adopt.)
The obvious problems are that people can't remember things at the drop of a hat just because you want them to, and people have trouble coming up with good passwords (especially at the drop of a hat). So people write down their new password, which is much more likely to be a weak password, because it's much easier to come up with (and remember) weak passwords than strong random ones.
But the direct, obvious problems pale next to the big one: frequent password changes train people not to take security seriously. Being made to change your password frequently is so obviously security theatre (especially if it's treated as a big deal) that it undermines everything else; when you engage in one obvious bit of security theatre, people are predisposed to assume that everything else is also security theatre.
(Remember that most people don't understand security (and probably aren't interested in doing so), and so they have to trust your judgement. But if they wind up feeling that your judgement is clearly flawed on one bit of security practice, this inevitably lessens their trust in all of your judgements.)
This leads me to a suggestion: if you are forced by higher powers to implement mandatory password changes, at least acknowledge to your users that it is a stupid idea (and ideally work with them to make it as painless as possible, for example by teaching them how to come up with one strong password that they can then vary back and forth).
(Yes, I'm aware that this may be politically infeasible.)