I'm not sure of the point of this mine-is-bigger-than-yours argument, but:
The earliest stream-I/O-system-based tty driver I'm aware of was
already in the Research kernel when I interviewed at Bell Labs
in early 1984. I have a vague memory that it was a couple of
years older than that, and was first implemented in a post-V7
PDP-11 system; also that I had heard about it first at a USENIX
conference in 1982 or 1983; but I cannot find any citations to
back up either of those memories.
I do know that I'd heard of it while I was still working at Caltech,
because I remember thinking about what a good idea it was and
about possibly trying to do my own version of it, but I never did.
I left Caltech at the end of June 1984, spent the following month
touring nearly the entire Amtrak long-distance network in a single
long reservation (it was possible to do that with surprisingly few
overnight stops off the train in those days), and started at Bell
Labs at the beginning of August.
Norman Wilson
Toronto ON
It sounds like my understanding of the different 4.1x versions is
just mistaken. If 4.1c had FFS and sockets, the kernel on which
V8 was built must have been an earlier 4.1x.
I believe the reason for adopting that kernel, rather than sticking
with 32/V, was exactly to get paging support. There was a competing
32/V descendant with paging, written by John Reiser at Holmdel, which
I gather was thought by many to be much cleaner technically; e.g. he
unified the block-device buffer cache and the memory-page cache, and
implemented copy-on-write paging rather than resorting to the messy
vfork. I have heard that there was considerable argument and
hand-wringing over whether to use Reiser's kernel or the BSD one.
It all happened well before I arrived, and I don't know what the
tradeoffs were, though one was certainly that Reiser's management
didn't support his work and nobody in 1127 was keen to have to take
it over.
Norman Wilson
Toronto ON
Joerg Schilling:
The colon was introduced by AT&T around 1983. It was used for Bourne Shell
scripts. Some of these scripts made it into SVr4 and caused problems with
non-Bourne compatible other shells.
====
Interesting. I never knew of that convention. I remember seeing
shell scripts with a : at the front, but thought that was just to
make sure the first character wasn't # even if the script began with
a comment.
Since some here had never heard of the #-means-csh convention, I
should perhaps explain about :. In pre-Bourne shells that used the
simple external control-flow mechanisms that I think were discussed
here a few months ago, : was used to mark a label: goto(1) would
seek to the beginning of its standard input, then read until it
encountered a line of the form
: label
with the desired label, then exit with the seek pointer at the first
character of the following line.
: was a no-op command; I forget whether it was implemented within the
shell or externally. Either way, that made it useful as a comment
character, but somewhat clumsy: it was just a command, with no
special parsing rules attached. A comment using : had to begin at
a command boundary, and its arguments were parsed in the normal way:
rm -rf * : you don't want to do this
was probably not what you wanted, instead you had to type
rm -rf * ; : "you don't want to do this"
or the like.
csh used # as a comment character from the beginning. Bourne
adopted it too.
Norman Wilson
Toronto ON
Random832:
The existence of cd as a real command is a bit silly (Ubuntu doesn't
seem to bother with it), but it is technically required by the standard.
===
Just for the record, Fedora 21 supplies /bin/cd, as part
of package bash-4.3.42-1. Interestingly, it is a shell
script:
lu$ cat /bin/cd
#!/bin/sh
builtin cd "$@"
lu$
As has been said here, it's hard to see the functional point.
Others have remarked on the continued life of /bin/true and
/bin/false. There are some who use those as shells in /etc/passwd
for logins that should never actually be allowed to do anything
directly. I have no strong personal feeling about that, I'm just
reporting.
And to be fair (as has also already been displayed here), the
copyright notice inserted in the once-empty /bin/true was hundreds
of bytes long, not thousands. Let us call out silliness, but let
us not make it out as any sillier than it actually is.
Norman Wilson
Toronto ON
UNIX old fart and amateur pedant
I remember reading about #! in the early 1980s, and
having mixed feelings about it, as I still do. The
basic idea is fine, if annoyingly limited; but that
the kernel has to decide, in effect, whether to treat
a header as binary or text bothers me. Were I designing
a new system from scratch today, I'd just make the
header all text; the small extra space and time for
the kernel to parse that for binaries doesn't matter
any more. It certainly did when #! was invented,
though.
I had the impression at the time that it came from
Berkeley, but I think I later heard from the horse's
mouth that it was originally Dennis's idea.
I don't think anyone has yet laid out the complete
story of what came before:
1. Originally, the shell would exec(file), and if
exec returned ENOEXEC, would open the file and treat
it as shell commands.
2. Then came the C shell, and a problem: did file
contain commands for csh or sh? A hack emerged:
if csh encountered a script file, it would read
the first character; if that was '#' it was a
csh script, otherwise it handed off to /bin/sh.
None of this helped when some program other than
the shell called exec on a shell script. That's one
reason execlp and execvp appeared. (The other is that
they observe $PATH if the command pathname has a
single element.)
I don't know offhand whether there was ever an execlp/vp
that implemented the #-means-csh convention. Anyone
else remember?
Norman Wilson
Toronto ON
> 8th edition was essentially a re-port of 4.1c BSD, correct?
"Re-port" may be a bit strong. Internet stuff from Berkeley
was folded into the research code (for a huge increase in
kernel size). But I think it was done by pasting Berkeley
code into local source, rather than the other way around.
But, since much of the rest of the BSD kernel was Bell
Labs code, it's probably right that the result of the
merge had more code in common with BSD than with Research.
If you ask, though, what fraction of Research code
survived the merge, it was probably larger than the
surviving fraction of the total BSD code.
Doug
> IIRC #! originated at Bell Labs but it got out to the world via BSD.
> Perhaps Dr. McIlroy could confirm / deny / expand upon the details (please?)
I recall Dennis discussing the feature at some length before installing it.
So the exact semantics, especially the injected argument, are almost]
certainly his. I don't know whether he built on a model from elsewhere.
#! appeared between v7 (1979) and v8 (1985). As v8 was never released,
it clearly made its way into the world via BSD and USG. BSD, being
more nimble, was likely first.
doug
On 9 September 2016 at 17:15, Mary Ann Horton <mah(a)mhorton.net> wrote (in part):
> When I was at Berkeley working on my dissertation, I wrote a tool that would
> let you edit a text file written in any language you could define with a
> grammar, with syntax and semantic error checking while you edited. I had
> grammars for several popular (in 1980) languages.
My curiosity is piqued. What were these languages?
N.
On 10 September 2016 at 05:41, Joerg Schilling <schily(a)schily.net> wrote:
> Michael Kjörling <michael(a)kjorling.se> wrote:
>
>> On 10 Sep 2016 09:45 +0200, from dnied(a)tiscali.it (Dario Niedermann):
>> > Il 15/07/2016 alle 14:27, Norman Wilson ha scritto:
>> >> lu$ cat /bin/cd
>> >> #!/bin/sh
>> >> builtin cd "$@"
>> >> lu$
>> >
>> > But doesn't this change the current dir only in the child shell?
>> > Which then exits right after the second line, parent shell's $PWD
>> > unaffected. I really don't see how this script is useful.
>>
>> It does appear rather useless. Curiously, Debian (checked on Wheezy =
>> bash 4.2+dfsg-0.1+deb7u3 and Jessie = bash 4.3-11+b1) seems to not
>> supply anything like that, so it would appear to be some kind of
>> Fedora-ism rather than a part of anything upstream; that, or the
>> Debian folks are actually paying attention to what they ship onto
>> users' systems.
>
> POSIX requires some commands to be callable via exec().
Solaris 10 has the following amusing implementation (/usr/bin/cd):
#!/bin/ksh -p
#
#ident "@(#)alias.sh 1.2 00/02/15 SMI"
#
# Copyright (c) 1995 by Sun Microsystems, Inc.
#
cmd=`basename $0`
$cmd "$@"
N.
