Wandering Thoughts archives


Why shells should have small programming languages

In light of things such as Perl and Python, it is reasonable to ask why the shell should have any sort of programming environment or language at all. Why not just restrict shells to simple commands, pipelines, and redirections?

(I'm assuming here that you have a good Unix glue language around for everything that people currently write shell scripts for.)

The obvious problem is the issue of where you draw the line. Is looping over lists of files and doing something to each of them a common enough operation that you should include it? How about conditional execution, so that you can only do one thing if the previous thing succeeded?

(That's a feature that you probably want in some form, because it makes a number of things much safer in the face of potential typos and so on.)

Where the line should be depends on what sort of operations you think that people routinely perform at the command line, which depends on your user community (or target user community), which means that there is no correct answer, only lots of arguments (or different shells).

The more subtle issue is the problem of initializing the shell's environment. Dotfiles can sensibly be reasonably complex (especially in a multi-architecture and multi-Unix environment with shared home directories), so you can easily need quite a bit of expressive power (conditional checks, loops to check this and that and the other, and so on). There's ways around this, such as using an entirely separate language for this purpose, but they aren't entirely pretty.

(Limiting the complexity of what people can do in their dotfiles makes the problem worse, because it doesn't make the need go away, it just forces people to do things in a more indirect and unreadable way.)

unix/WhyShellLanguages written at 00:02:09; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.
