ARNnet have an Interview with Steve Bourne (dated 5th March 2009).
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.
I have nearly finished reading Coders At Work - Steve Bourne could have been an interesting interviewee for that book.
Update When I posted this link, I was not aware that this very site was linked to, at the top of page 5 of the 7-page interview.
One of the questions posed, was:
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. I 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 think that the points were presented to Steve Bourne in reverse order; his answer to the first point seems to relate to "b" (quality of scripts), and his longer answer to the second point seems to relate to "a" (performance).
Regarding performance, as he says, the real cost is of the Unix exec() call, which makes "cat /etc/hosts | grep localhost" half as fast as "grep localhost /etc/hosts". There is nothing that the shell itself can do about that.
Regarding quality, deliberately obfusacated C is an institution; my point was merely that it is easy to write a bad shell script simply by not knowing how to write a better shell script. As this quote was from the introduction to a shell scripting tutorial, it should hopefully be clear from the context that the tutorial aims to enable the reader to write better shell scripts.
Comments for 'Rare interview with Steve Bourne, the man behind the Bourne Shell (#!/bin/sh)'
You could post a comment if you were logged in.
You are logged in as 0
Steve's urandom blog