Steve Bourne Talks About the History of Sh 232
An anonymous reader writes "Steve Bourne, the creator of the Bourne shell, or sh, talks about its history as the default Unix shell of Unix Version 7. Bourne worked on the shell in 1975 and said the process took no more than 6 months. Sh aimed to improve on the Thompson shell. 'I did change the shell so that command scripts could be used as filters. In the original shell this was not really feasible because the standard input for the executing script was the script itself. This change caused quite a disruption to the way people were used to working. I added variables, control flow and command substitution. The case statement allowed strings to be easily matched so that commands could decode their arguments and make decisions based on that. The for loop allowed iteration over a set of strings that were either explicit or by default the arguments that the command was given.
I also added an additional quoting mechanism so that you could do variable substitutions within quotes. It was a significant redesign with some of the original flavor of the Thompson shell still there. Also I eliminated goto in favour of flow control primitives like if and for. This was also considered rather radical departure from the existing practice.
Command substitution was something else I added because that gives you very general mechanism to do string processing; it allows you to get strings back from commands and use them as the text of the script as if you had typed it directly. I think this was a new idea that I, at least, had not seen in scripting languages, except perhaps LISP,' he says."
perl (Score:3, Interesting)
I've never fully understood why bash is used anymore when perl is around.
No I'm not trolling. in most applications that take a significant amount of time to run, perl is orders of magnitude faster than equivalent and akward bash script.
the syntax of perl is sufficiently close to bash that anyone fluent is bash ought to have little trouble with moving to perl.
So in total seriousness, what is the point of using bash for scripting?
Re:PowerShell (Score:2, Interesting)
Oh, how I wish they would copy UNIX. File management would almost be tolerable.
--Brought to to you by the letters "c" and "p".
Re:perl (Score:2, Interesting)
Write a perl shell then, and see how it's received?
Compiler research (Score:3, Interesting)
I wonder if the bell labs researchers got the eureka moments when their applied research in compilers worked like the CERN physicists detect a theoretical particle.
Re:Do windows users need a shell? (Score:5, Interesting)
You can use perl and python for windows.
For example, for perl there's Bundle::Win32
http://search.cpan.org/~jdb/Bundle-libwin32-0.30/libwin32.pm [cpan.org]
Useful stuff like: Win32::TieRegistry , Win32::ChangeNotify
But be good and don't write malware. The antivirus people might give up trying to detect perl malware (think about it - polymorphic TMTDOWTDI perl malware...), they might just flag/blacklist perl itself :).
This inspired me to write a tiny *NIX shell (Score:2, Interesting)
I saw this article on OSnews this morning, and it inspired me to write a tiny open-source (public domain) *NIX shell, which can be seen at http://www.samiam.org/software/yash.html. I know the busybox [busybox.net] guys are looking to rewrite their *NIX shell to be more modular; this code would be a good starting point.
- Sam
Re:PowerShell (Score:2, Interesting)
Many Mac users have found the Unix shell hidden under Mac OS X to be quite useful. And, remember that pre Mac OS X, not only didn't the Mac OS have the concept of environment variables. It didn't even have a command line prompt.
Of course, it isn't just the shell, it's the whole OS philosophy that's important. It's why people who use Linux/Unix based systems can easily cobble together their own backup solutions. Use "rsync" with Amazon's S3 service, and you have an online backup solution that's cheap and secure.
Even better, you can even design the whole thing to run as a cronjob. Do the backup at 3AM when no one is using your computer.
It is one of the reasons that the first thing I do whenever I get a Windows computer is install Cygwin on it.
Re:perl (Score:4, Interesting)
Are you saying people should use Perl as an interactive shell? Or are you saying people should never use bash non-interactively?
The entire concept behind 'shell scripting' is to make it easy to tie together the same commands you type into the interactive shell. When I get used to doing 'rm' and 'cp' I can write an easy shell script which does the two together.
Of course, once you get to large shell scripts, then it becomes much more sane to use a real language rather than a shell script.
The Unix Shell and Scripting Languages (Score:4, Interesting)
Backticks? Why on earth would you use backticks to move files around? That's what File::Copy is for. And Archive::Tar handles tarballs.
Write Perl code, not shell scripts wrapped in Perl code.
All of this raises an issue that interests me, with regard to the shell and scripting languages...
The shell is supposed to be a convenient interface for accessing the functionality your system has to offer - but because of the way that functionality is offered it's hard to take advantage of it. The shell hasn't got much in the way of support for datatypes, namespaces, and so on. This makes it a lot easier (and, often, more efficient) to program in a scripting language like Perl or Python, and implement all kinds of useful functionality as libraries for that language, instead of as shell programs.
So scripting languages have the advantage of providing a much more structured and full-featured programming environment - a better foundation on which to build more complicated programs and more sophisticated tools. But the whole thing is one degree separated from the normal interaction with the shell - it's not trivial to expose all that functionality implemented for the scripting language to code outside the scripting language... The scripting language becomes a rich environment all its own, but that functionality isn't part of the shell environment, because the shell environment doesn't support the organizational concepts that make that code manageable within the framework of the scripting language.
I feel like this situation is a problem - I believe in what some people call "The Unix Way" - chaining together small tools to do bigger jobs, but the shell doesn't have the organizational constructs to make this work for complex problems - and as a result people are doing this great work on adding functionality to the system, but it's getting packaged up as scripting language modules since the shell can't handle it. It's something I'd really like to correct.
Cambridge Phoenix system (Score:3, Interesting)
Re:Real history. (Score:3, Interesting)
P1: I wrote my first /bin/sh script on 9/10/1984
P2: I'm still in touch with the other intern from that phase, who calls me and asks things like, "Is it 2>&1 or 2&>1? I never can remember..."
C: Long term usage does not imply expertise.
I like to think I'm pretty good, but I still review Csh Programming Considered Harmful [faqs.org] for more esoteric usage of /bin/sh, when I have only that old tool available.