Steve Bourne Talks About the History of Sh

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."

Re:Greenspun's Tenth Rule

[Sir Groane]

Because Steve Bourne was doing this work back in 1975! About that time people had only just got beyond programming by biting holes in paper-tape with their teeth!

These days it is quite easy to get embedded perl or lisp etc.

Re:perl

[goombah99]

If all you're doing is moving files around or creating tarballs etc. then all those backticks in perl can become a PITA

it's easy to wrap shell into perl when one feels the backtick are getting in the way. To be pendantic:

<perl commands go here >

system <<EOC; # the bash script follows
echo "embedded bash script begins"
ls /tmp
tar -xc fooberries.tar /tmp
mv tweedlee.txt tweedeldum.txt
echo "bash script done, now resuming perl interpreter"
EOC

<further perl commands here.>

Re:Do windows users need a shell?

[RAMMS+EIN]

The question, though, is why C# or Java "programming" is so different from "scripting" that you'd expect a sysadmin to know the latter, but not the former.

Re:perl

[frenchbedroom]

Bash is also a command line interpreter. This allows you to try out stuff before writing a script, which you can also do in the same environment : just use cat.

Just try this :
$ perl
ls

What ? No output ? :)

Windows Script Host

[tepples]

Does Windows seriously not come with any way to automate things?

Windows Script Host [wikipedia.org] allows a program written in JScript or VBScript to control any app that exposes APIs through OLE Automation [wikipedia.org].

Yes, PowerShell

[benjymouse]

Available from Microsoft for XP, 2003; included in Server 2008 and Windows 7.

The name is really lame, but it *is* damn powerful. At least for Windows which has most of it API exposed through object-oriented technologies (COM, .NET and WMI) which are easily used in a unified way by PowerShell.

Just a few quick samples:

• List all .exe files in current dir and below: ls -r . *.exe
• Calculate their combined size: ls -r . *.exe | measure -sum Length
• Find the latest version of all .exe files below the current directory: ls -r . *.exe | sort -des LastWriteTime | group Name | %{$_.Group[0]}
• Instead of finding the latest, delete those with a more recent version somewhere: ls -r . *.exe | sort -des LastWriteTime | group Name | %{$_.Group|select -skip 1} | rm
• Read files and directories from current directory out loud through the speakers: $sam=new-object -com SAPI.SPVoice; ls | %{$sam.Speak($_)}
• List processes consuming (the "working set") more than 100MB: ps|?{$_.WS -gt 100MB}
• -Kill them instead: ps|?{$_.WS -gt 100MB}|kill
• Wait for the "import" process to exit: (ps "powershell_ise").WaitForExit()

Why so verbose?

[benjymouse]

when

ls -r | ?{-not($_|ls)}

would suffice?

Explanation:

1) list all items recursively from the current location

2) filter only those items where ls returns an empty set.

Btw, the objects returned from that command are *still* DirectoryInfo objects, allowing even further operations or property accesses.

Also, this command will work the same even if the "current location" is a node in the registry, the certificate store, the credentials store, a group in active directory etc etc.

In other words if you change the location to an organisational unit in AD, the exact same command will find empty sub-containers.

Command substitution a "new idea?"

[dpbsmith]

"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."

Surely this feature was present in Calvin Mooer's TRAC [wikipedia.org], circa 1964 or thereabouts. I've forgotten the distinction between expanded macros by means of single or double slashes, but I believe one or the other of them substituted the macro expansion back in the stream for further processing. My recollection is that it was fundamental to the way TRAC was used in practice. My recollection is also that TRAC was moderately well-known in the community at the time, so the idea was "in the air."

I believe it also existed in a host of "macro" capabilities in assembly languages... familiar to me in MIDAS, an assembly language for the PDP-1 circa 1965 or so. MIDAS survived into the PDP-6 and PDP-10, may have been developed earlier for the TX-0, and I think may have been patterned on advanced macro assemblers for the IBM 709.

My /bin/sh rules

[SpaghettiPattern]

As an IT pro, I recognize the significance of /bin/sh and I am very grateful for to Steve Bourne for his creation. It's the smallest (that's a good thing), consistent and standardized command set for setting up environments to run programs.

My scripting rules on UNIX like systems:

• Anything that can be done in /bin/sh I DO in /bin/sh.
• Anything slightly more complex I do in Perl.
• Anything truly complex I write in Java.
• For writing scripts I NEVER, EVER use slightly enhanced shells like (t)csh (know for having bugs), ksh (used to be proprietary) or bash (too many features I DON'T want for simple scripts).
• People that resort to slightly enhanced shells for scripting qualify themselves as being ... let's say ... inexperienced.
• It pisses me off when I have to look up special csh, ksh or bash constructs in order to understand scripts.
• Fancy variables? Reconsider or write Perl.
• Fancy condition checking? Reconsider or write Perl.
• Fancy arithmetic? Reconsider or write Perl.
• Fancy system access (e.g. ipc)? Write Perl.
• However, my favorite INTERACTIVE shell is bash. It gets the /bin/sh syntax and offers stuff that makes you extremely quick when working interactively.