The A-Z of programming languages: Bourne shell

1 2 3 Page 2
Page 2 of 3

Looking back, is there anything you would change in the language's development? In the language design I would certainly have added functions earlier. I am rather surprised that I didn't do that as part of the original design. And the other thing I would like to have done is written a compiler for it. I got halfway through writing a shell script compiler but shelved it because nobody was complaining about performance at the time.

I can't think of things that we would have done particularly differently looking back on it. As one of the first programmable scripting languages it was making a significant impact on productivity.

If the language was written with the intention of being a scripting language, how did it become more popular as an interactive command interpreter? It was designed to do both from the start. The design space was you are sitting at the terminal, or these days at the screen, and you're typing commands to get things done. And it was always intended that that be one of the primary functions of the shell. This is the same set of commands that you're accessing when you're in a shell script because you're (still) accessing the Unix environment but just from a script. It's different from a programming language in that you are accessing essentially the Unix commands and those capabilities either from the terminal or from the script itself. So it was originally intended to do both. I have no idea which is more popular at this point; I think there are a lot of shell scripts around.

Many other shells have been written including the Bourne Again shell (Bash), Korn Shell (ksh), the C Shell (csh) and variations such as tcsh. What is your opinion on them? I believe that Bash is an open source clone of the Bourne shell. And it may have some additional things in it, I am not sure. It was driven (I'm sure everybody knows this) from the open source side of the world because the Unix license tied up the Unix intellectual property (source code) so you had to get the license in order to use it.

The C shell was done a little after I did the Bourne shell -- I talked to Bill Joy about it at the time. He may have been thinking about it at the same time as I was writing sh but anyway it was done in a similar time frame. Bill was interested in some other things that at the time I had less interest in. For example, he wanted to put in the history feature and job control so he went ahead and wrote the C shell. Maybe in retrospect I should have included some things like history and job control in the Unix shell. But at the time I thought they didn't really belong in there ... when you have a window system you end up having some of those functions anyway.

I don't recall exactly when the Korn shell was written. The early 80s, I suspect. At the time I had stopped adding "features" to sh and people wanted to continue to add things like better string processing. Also POSIX was being defined and a number of changes were being considered in the standard to the way sh was being used. I think ksh also has some csh facilities such as job control and so on. My own view, as I have said, was that the shell had reached the limits of features that could be included without making it rather baroque and certainly more complex to understand.

Why hasn't the c shell (and its spawn) dropped off the edge of the planet? Is that actually happening? I don't know, is it? There are a lot of scripts that people would write in the C shell. It has a more C-like syntax also. So once people have a collection of scripts then it's hard to get rid of it. Apart from history and job control I don't think the language features are that different although they are expressed differently. For example, both languages have loops, conditionals, variables and so on. I imagine some people prefer the C-style syntax, as opposed to the ALGOL68-like syntax of the shell.

There was a reason that I put the ALGOL-like syntax in there. I always found, and this is the language design issue, that I would read a C program and get to a closing brace and I would wonder where the matching opening brace for that closing brace was. I would go scratching around looking for the beginning of the construct but you had limited visual clues as to what to look for. In the C language, for example, a closing brace could be the end of an if or switch or a number of other things. And in those days we didn't have good tools that would allow you to point at the closing brace and say 'where's the matching opening brace?'. You could always adopt an indenting convention but if you indented incorrectly you could get bugs in programs quite easily because you would have mismatching or misplaced brace. So that was one reason why I put in the matching opening and closing tokens like an if and a fi -- so all of the compound statements were closed and had unique closing tokens.

And it was important for another reason: I wanted the language to have the property that anywhere there was a command you could replace it with any closed form command like an if ... fi or a while ... do ... done and you could make that transformation without having to go re-write the syntax of the thing that you were substituting. They have an easily identifiable start and end, like matching parentheses.

Compare current UNIX shells (programs that manipulate text) and new MS Windows Power Shell (classes that manipulate objects). Would Unix benefit from a Power Shell approach? The Unix environment itself doesn't really have objects ... if you look at what the shell is interfacing to, which is Unix. If objects are visible to the people writing at the shell level then it would need to support them. But I don't know where that would be the case in Unix; I have not seen them. I imagine in the Microsoft example objects are a first class citizen that are visible to the user so you want to have them supported in the scripting language that interfaces to Windows. But that is a rather generic answer to your question; I am not specifically familiar with the power shell.

Is Bash a worthy successor to Bourne shell? Should some things in Bash have been done differently? I believe you can write shell scripts that will run either in the Bourne shell or Bash. It may have some additional features that aren't in the Bourne shell. I believe Bash was intended as a strictly compatible open source version of the Bourne shell. Honestly I haven't looked at it in any detail so I could be wrong. I have used Bash myself because I run a Linux/Gnu system at home and it appears to do what I would expect.

Unix Specialist Steve Parker has posted 'Steve's Bourne / Bash scripting tutorial' in which he writes: Shell script programming has a bit of a bad press amongst some Unix systems administrators. This is normally because of one of two things: a) The speed at which an interpreted program will run as compared to a C program, or even an interpreted Perl program; b) Since it is easy to write a simple batch-job type shell script, there are a lot of poor quality shell scripts around. Do you agree? It would be hard to disagree because he probably knows more about it than I do. The truth of the matter is you can write bad code in any language, or most languages anyway, and so the shell is no exception to that. Just as you can write obfuscated C you can write obfuscated shell. It may be that it is easier to write obfuscated shell than it is to write obfuscated C. I don't know. But that's the first point.

The second point is that the shell is a string processing language and the string processing is fairly simple. So there is no fundamental reason why it shouldn't run fairly efficiently for those tasks. I am not familiar with the performance of Bash and how that is implemented. Perhaps some of the people that he is talking about are running Bash versus the shell but again I don't have any performance comparisons for them. But that is where I would go and look.

okI know when I wrote the original implementation of the shell I spent a lot of time making sure that it was efficient. And in particular with respect to the string processing but also just the reading of the command file. In the original implementation that I wrote, the command file was pre-loaded and pre-digested so when you executed it you didn't have to do any processing except the string substitutions and any of the other semantics that would change values. So that was about as efficient as you could get in an interpretive language without generating code.

I will say, and it is funny because Maurice Wilkes asked me this question when I told him what I was doing, and he said 'how can you afford to do that?' Meaning, how can you afford to write programs when the primitives are commands that you are executing and the costs of executing commands is so high relative to executing a function in a C program, for example. As I have said earlier, the primary performance limitation is that you have to do a Unix fork and exec whenever you execute a command. These are much more expensive than a C function call. And because commands are the abstraction mechanism, that made it inefficient if you are executing many commands that don't do much.

Where do you envisage the Bourne shell's future lying? I don't know; it's a hard question. I imagine it will be around as long as Unix is around. It appears to be the most ubiquitous of the Unix shells ...What people tell me is if they want one that is going to work on all the Unix systems out there in the world, they write it in the Bourne shell (or Bash). So, that's one reason. I don't know if it is true but that is what they tell me. And I don't see Unix going away any time soon. It seems to have had a revival with the open source movement, in particular the GNU Project and the Linux kernel.

Where do you see shells going in general? As I have said the shell is an interface to the Unix environment. It provides you with a way of invoking the Unix commands and managing this environment interactively or via scripts. And that is important because if you look at other shells, or more generally scripting languages, they typically provide access to, or control and manipulate, some environment. And they reflect, in the features that are available to the programmer, the characteristics of the environment they interface to. It's certainly true the Unix shells are like that. They may have some different language choices and some different trade offs but they all provide access to the Unix environment.

So you are going to see languages popping up and shells popping up. Look at some of the developments that are going on with the Web -- a number of languages have been developed that allow you to program HTML and program Web pages, such as PHP. And these are specific to that environment. I think you are going to see, as new environments are developed with new capabilities, scripting capabilities developed around them to make it easy to make them work.

How does it feel to have a programming language named after you? People sometimes will say to me 'oh, you're Steve Bourne' because they are familiar with the shell. It was used by a lot of people. But you do a lot of things in your life and sometimes you get lucky to have something named after you. I don't know who first called it the Bourne shell.

I thought it was you that named it Bourne? No. We just called it the shell or sh. In the Unix group back in the labs I wrote a couple of other programs as well, like the debugger adb, but we didn't call that the Bourne adb. And certainly we didn't call it the Aho awk. And we didn't call it Feldman make. So I didn't call it the Bourne shell, someone else did. Perhaps it was to distinguish it from the other shells around at the time.

Where do you see computer programming languages heading in the future, particularly in the next 5 to 20 years? You know I have tried to predict some of these things and I have not done very well at it. And in this business 20 years is an eternity. I am surprised at the number of new entrants to the field. I thought that we were done with programming language designs back in the late 70s and early 80s. And maybe we were for a while. We had C, C++ and then along comes Java and Python and so on. It seems that the languages that are the most popular have a good set of libraries or methods available for interfacing to different parts of the system. It is also true that these modern languages have learned from earlier languages and are generally better designed as a result.

Since I was wrong in 1980 when we thought 'well we are done with languages, let's move on to operating systems, object oriented programming, and then networking' and whatever else were the other big problems at the time. And then suddenly we get into the Internet Web environment and all these things appear which are different and improved and more capable and so on. So it is fun to be in a field that continues to evolve at such a rapid pace.

You can go on the Internet now and if you want to write, for example, a program to sort your mail files, there is a Python or Perl library you will find that will decode all the different kinds of mail formats there are on the planet. You can take that set of methods or library of functions and use it without having to write all the basic decoding yourself. So the available software out there is much more capable and extensive these days.

I think we will continue to see specialized languages; such as PHP which works well with Web pages and HTML. And then look at Ruby on Rails. Who would have thought LISP would come back to life. It is fun to be an observer and learn these new things.

1 2 3 Page 2
Page 2 of 3
Shop Tech Products at Amazon