Bennett Todd bet at
Wed Jul 14 11:18:48 PDT 2004

2004-07-14T17:08:52 Björn Lindberg:
> This is sort of what I mean; bash was developed during and after the
> POSIX standardization took place, and was intended to follow the
> specification.

My recollection is that bash was developed as a /bin/sh replacement
with some enhancements, well before POSIX started looking at /bin/sh
--- or at least before their looking was publicly discussed.

The enhancements grew over time; for sure one source of ideas
for enhancements was ksh, particularly when bash tracked POSIX
standardization development. But the development was for sure
independent, resulting in particular in a shell whose finger-feel in
the cmdline editing and completion was wildly different, and whose
scripting wasn't compatible in the funky extensions, only in the
POSIX core, which seems to be not too dissimilar from classic
/bin/sh, at least from the docs you pointed me to earlier.

> Thus, it is my impression that bash did not influence the
> standardization process much, but rather just following it.

I don't know whether it influenced it or not, but it definitely
developed its POSIX compatibility contemporary with POSIX designing
their spec.

> ksh -- in contrast -- and in particular the wide-spread ksh88
> version, was developed before the POSIX effort, and influencing
> the standards work to a much greater degree.

Yup. No question. And if it had been open source, perhaps the
influence would have resulted in a compatible shell at the time,
either from POSIX more precisely picking up the changes exactly, or
ksh being adjusted to track POSIX at the time rather than sometime

> It seems to me that all modern shells today (meaning those based
> on the Bourne shell of course; so tcsh, rc, es, etc. excluded)
> derive in their functionality and syntax from ksh, which in turn
> laid the basis for the POSIX standard.

They all derive their syntax and functionality from the classic
Bourne Shell. A few features were picked up ksh by way of POSIX,
although not unmodified; ksh88 wasn't POSIX compatible.

> I appreciate your input, since you were there when it happened, so
> to speak. :-)

Thanks, I was there, although I gotta confess that was a long time
ago, the memories are a little fuzzy. As am I for that matter:-).

> > Bash was available long before 2.0, it was one of the earlier major
> > GNU programs --- understandably, it's nearly as fundamental as an
> > emacs and a C compiler.
> I see. But when would you estimate that it was usable, and when was it
> starting to become POSIX-compliant? Looking at the release numbers and
> the release dates, it seems that 2.0 was a milestone of sorts. Is that
> correct?

bash was seriously useable in the late 1980s. Wish I could find some
bash1 history somewhere. I _believe_ Brian Fox originally wrote it,
Chet Ramey launched a CWRU fork that was later consolidated back
as the lead thread of bash 1.x, that being sometime around 1990 or
so maybe. I've got this vague recollection that the fancy readline
editing/history/completion was born on that branch, but I may be

2.0 was a major new release, but by no means the first widely-used
and useable one; there's still a bash1 branch being maintained and
available in various *BSD ports and Linux distros.

> > Long before Linux came around, many of us enjoyed working on
> > other Unix systems, and for at least some of us, the standard
> > working pattern was to put all the GNU stuff into /usr/local/bin
> > and put that at the front of our PATH, giving us the finger-feel
> > of a GNU system wherever we were.
> Ah, interesting. Why was that? Was the GNU tools percieved as
> superior, or was it based on ideological reasons?

I can't speak for everyone who did this; it was a widespread habit,
different folks probably had different motivations.

For me it was a mix, although I wouldn't call any of the reasons
idiological. I'd long since started pursuing open source
alternatives by strong preference for base tools; I got launched on
that habit when I switched text editors for the last time, in 1983,
to JOVE; prior to that my favourite text editor was PC-Write,
breathtakingly fast and used the function keys very well, but a
binary-only DOS-only app. Once I switched to jove and learned it I
never had to learn another.

But with the basic Unix /bin and /usr/bin utils, there was a more
pragmatic reason: the Unix utilities generally had serious input
size limitations of various sorts. I blew up grep with a hairy
regexp very early in my career, downloaded Henry Spencer's regexp
lib and wrote my own grep which didn't blow up. The GNU tools were
being written to be robust and free of arbitrary buffer size limits,
and were getting nice enhancements. One I remember from early on was
the find ... -print0 | xargs -0 ... pair that lets you safely
process files even if they've got Funky Chars in their filenames.

> > But my real favourite shell is so different from both that it dodges
> > the whole issue. rc rules!
> I have been meaning to look into both rc and es, but never found time
> for it. For what do you prefer rc, ie for scripting or interactive
> use, and why? What are the most important features of rc compared to
> ksh93 or bash?

I've lost track of es, I remember being fond of it, I should hunt it
down again and add it to my repertoire.

As I recall, es is a nearly completely upward-compatible extension
to rc, that adds a powerful mechanism for extending the shell.
That's vague but that's all I can trawl up.

rc is a shell devised by Rob Pike for Plan 9, with several goals:

 - be an unsurprising, routine Unix shell, simple cmdline use works
   as expected

 - solve /bin/sh's quoting complexity. rc has exactly one kind of
   quote, the single-quote, which quotes everything until the
   matchnig single-quote, and the only internal interpretation is
   that a pair of adjacent single-quotes get collapsed to one. Other
   than that, everything is literal:

	; echo 'Hi there! I''ve got quotes in.'
	Hi there! I've got quotes in.

 - The big reason /bin/sh's quoting is such a nightmare is repeated
   passes of various sorts of variable expansion and interpolation
   applied one after another, at various points in time. This in
   turn is almost entirely because /bin/sh doesn't have lists, only
   simple strings, so they're constantly being whitespace-split and
   reassembled to simulate lists. So rc has lists.

I _think_ rc introduced the notion of nonlinear pipelines, now
available in many other shells; rc let you:

	; diff -u <{echo foo} <{echo bar}
	--- /tmp/rc5205.0       2004-07-14 14:12:01.000000000 -0400
	+++ /tmp/rc5205.1       2004-07-14 14:12:01.000000000 -0400
	@@ -1 +1 @@

rc uses its lists to handle pipeline exit status correctly:

	; sh -c 'false|true && echo that was true?'
	that was true?
	; rc -c 'false|true && echo that was true?'

The $status in rc after false|true is a list containing (1 0), and
unless all the numbers in a list are zero rc treats it as false.

rc is a _lot_ smaller than bash; with a libreadline statically
linked in (along with statically linked uClibc, completely static

	; ls -l /bin/rc /bin/bash
	-rwxr-xr-x    1 root     root       502228 May 24 03:29 /bin/bash
	-rwxr-xr-x    1 root     root       181332 May 24 10:51 /bin/rc

Oh, and my choice of prompts are straight from rc; its defaults,
reflecting another clever idea of Rob Pike's, is that (in /bin/sh
terms) PS1="; " and PS2="\t". So loop bodies type in indented when
you enter them interactively, and the prompt doesn't interfere with
the command's interpretation if you cut-n-paste a whole series of
commands into another shell. I've extended this sometimes, when I
want a more informative prompt (basically, everywhere except my base
system) I use a prompt that looks like (on hostname "foo")

	: foo; 

taking advantage of the ":" null command to gobble everything up to
the semicolon.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the lfs-chat mailing list