Because of the design bug I mentioned, I searched for UNIX sources from AT&T
that include streams support, but could never find any.
=====
None of the Research systems after 32/V was ever distributed except
to a handful of sites under site-specific letter agreements that
forbade redistribution.
This is a bug, not a feature, but there it is. It was easy to get
approval to write a paper, much harder to get permission to distribute
code, especially when the code in some way overlapped …
[View More]the Official
Product.
Warren and I (and Dennis, when he was still alive) hoped to do
something about some years back, but it's a lot harder than it used
to be because it is harder to find a corporate entity that is
confident enough to give permission, even for stuff that is so old
that it is unlikely to have a trumppenceworth of commercial value.
Then IBM vs SCO intervened, and now things are even more fragmented.
There may be other efforts under way now and then to negotiate the
legal minefield. I wish them all well, and will help them where I
can.
Norman Wilson
Toronto ON
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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
…
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
> 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 …
[View More]fraction of Research code
survived the merge, it was probably larger than the
surviving fraction of the total BSD code.
Doug
[View Less]
> 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 …
[View More]USG. BSD, being
more nimble, was likely first.
doug
[View Less]
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 …
[View More]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.
[View Less]
> From: Blake McBride
> After about 30 years of C, there are only three things I would have
> liked to see:
> 1. Computed goto
Can't you make a switch statement do what you need there?
The two things I really missed were:
- BCPL's ValOf/ResultIs, for making more complex macros (although with the
latest modern compilers, which inline small functions, this is less
of an issue)
- The ability to 'break' out of more than one level of nesting; one either
has to stand …
[View More]on one's head (code-wise), or use a goto
Noel
[View Less]
> After about 30 years of C, there are only three things I would
have liked to see:
> 1. Computed goto
...
> Computed goto's are good for interpreters.
A computed goto, of course, is merely an optimized switch.
Dennis installed this optimization early in the evolution of C. The
main driving force was the performance and size of the PDP-11 Unix
kernel. As functionality grew, resource usage was repeatedly tamped
down by improving C's code generation.
The switch optimizer chose …
[View More]among three strategies: naive, binary
decision tree, and computed goto, depending on the number and density
of switch alternatives. Hybrid strategies may have been used, too,
but my memory is hazy on this point. In particular the optimization
improved system-call dispatch--thus achieving the objective,
"good for interpreters". I assume (I hope not unrealistically)
that this optimization has been in the repertoire of mainline C
compilers ever since.
> (Or perhaps require C to support tail recursion.)
I can imagine making a strong recommendation in the standard for
optimizing switches and (at least direct) tail recursion.
Doug
[View Less]
I sent a similar message some time ago, but I haven't
seen it appear in the mailing list, so here goes again.
Apologies if it ends up as a duplicate.
> After about 30 years of C, there are only three things I would have liked
> to see:
>
> 1. Computed goto
> ...
> Computed goto's are good for interpreters.
A computed goto is an optimized switch, and that optimization
goes back to the original C compiler. Mostly driven by
considerations of size and speed of the Unix kernel, …
[View More]Dennis
quite early on taught the compiler to choose among three
compilation strategies for a switch: a chain of comparisons,
a tree of comparisons, or a computed goto, depending on the
number and density of alternatives.
The compilation of the system-call dispatch table was
a perfect example of "good for interpreters."
I have always assumed that other mainline compilers behave
similarly, but I have no solid knowledge about that.
doug
[View Less]
Seen on another list... And I got quoted by Steve Bellovin :-)
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
---------- Forwarded message ----------
From: Kent Borg
To: cryptography(a)metzdowd.com
Subject: Re: [Cryptography]
"NSA-linked Cisco exploit poses bigger threat than previously thought"
On 08/25/2016 06:06 PM, Steven M. Bellovin wrote:
> I first heard more or less that line from Doug McIlroy himself; he
> called C the best assembler …
[View More]language he'd ever used.
Ancient fun-fact: Years ago there was an article in Byte magazine
describing how a useful subset of C could be directly assembled into 68000
code. Not compiled, assembled.
C is a stunning assembly language. When those wild-eyed nerds at AT&T
decided to write Unix not in assembly but in C (where was management!?),
it was radical. But C was up to (down to?) the task, it was pioneering
then and is still doing useful things decades later: From the fastest
supercomputers to some pretty slim microcontrollers (plus a hell of a lot
of Android devices) multitudes of computers run a Linux kernel compiled
from the *same* C source code, with almost no assembly. Big-endian,
little-endian: no matter. Different word lengths: no matter.
That is one impressive cross-platform assembly language!
Unfortunately, C is also a dangerous language that mortal programmers
cannot reliably wield.
-kb, the Kent who knows he is pressing his luck on a moderated
cryptography mailing list, but C deserves a lot of respect, as it also
deserves to be efficiently sent into a dignified retirement.
_______________________________________________
The cryptography mailing list
cryptography(a)metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
[View Less]
Every time someone starts spouting about how unsafe
C is, and how all the world's problems would be solved
if only people would stop using it, I think of Flon's
Axiom, for 35 years my favourite one-liner about
programming and languages:
There does not now, nor will there ever, exist a
programming language in which it is the least bit
hard to write bad programs.
Flon's Axiom comes from a short note On Research
in Structured Programming, published in SIGPLAN
Notices in October 1975. It's …
[View More]just as true today.
Over the years I've seen people misinterpret the
Axiom as an argument against looking for better
programming languages at all, but that's not what
it means. (Read the original note--it's a page
and a half--for full context; it is, alas, behind
ACM's Digital Library paywall.) There are certainly
languages that make certain sorts of mistakes easier
or harder, or are easier or harder to read, but in
the end most of that really is up to the programmer.
Programming well requires a lot of thought and care
and careful rereading, and often throwing half the
code out and re-doing it better, and until we can
have a programming community the majority of whom
are up to those challenges, we will continue to have
crashes and security vulnerabilities and other
embarrassing bugs aplenty, no matter what language
is used.
Norman Wilson
Toronto ON
[View Less]
The latest issue of the IEEE Annals of Computing was published
electronically today, and it has an article that I expect many
TUHS list readers will enjoy reading:
Notes on the History of Fork and Join
http://dx.doi.org/10.1109/MAHC.2016.34
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department …
[View More]of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
[View Less]
All, sorry this is slightly off-topic. I'm trying to
find out what fstat(2) returns when the file descriptor
is a pipe. The POSIX/Open Group documentation doesn't
really specify what should be returned. Does anybody have
any pointers?
Thanks, Warren
P.S. Why? xv6 has fstat() but returns an error if the
file descriptor isn't associated with an i-node. I'm
trying to work out if/how to fix it.
I remember once, long ago--probably in the early 1980s--writing
a program that expected fstat on a pipe to return the amount of
data buffered in the pipe. It worked on the system on which
I wrote the code. Then I tried it on another, related but
different UNIX, and it didn't work. So if POSIX/SUS don't
prescribe a standard, I don't think one should pretend there
is one, and (as I learned back then) it's unwise to depend
on the result, except I think it's fair not to expect fstat
to fail on …
[View More]any valid file descriptor.
I'm pretty sure that in 7/e and earlier, fstat on a pipe
reported a regular file with zero links. There was a reason
for this: the kernel in fact allocated an i-node from a
designated pipe device (pipedev) file system, usually the
root. So the excuse that `there's no i-node' was just wrong.
In last-generation Research systems, when pipes were streams
(and en passant became full duplex, which caused no trouble
at all but simplified life elsewhere--I think I was the one
who realized that meant we didn't need pseudo-ttys any more),
the system allocated a pair of in-core i-nodes when a pipe
was created. As long as such an i-node cannot be accidentally
confused with one belonging to any disk file system, this
causes no trouble at all, and since it is possible to have
more than one disk file system this is trivially possible
just by reserving a device number. (In fact by then our
in-core i-nodes were marked with a file system type as well,
and pipes just became their own file system.) stat always
returned size 0 for (Research) stream pipes, partly because
nobody cared enough, partly because the implementation of
streams didn't keep an exact count of all the buffered data
all along the stream, just a rough one sufficient for flow
control. Besides, with a full-duplex pipe, which direction's
data should be counted?
Returning to the original question, I'd suggest that:
-- fstat(fd) where fd is a pipe should succeed
-- the file should be reported to have zero links,
since that is the case for a pipe (unless a named pipe,
but if you support those you probably have something
else to stat anyway)
-- the file type should be IFIFO if that type exists
in xv6 (which it wouldn't were it a real emulation of
6/e, but I gather that's not the goal), IFREG otherwise
-- permissions probably don't matter much, but for
sanity's sake should be some reasonable constant.
Norman Wilson
Toronto ON
[View Less]
> From: Warren Toomey
> xv6 is a Unix-like OS written for teaching purposes.
I'm fairly well-aware of Xv6; I too am planning to use it in a project.
But back to the original topic, it sounds like there's a huge amount of
variance in the semantics of doing fstat() on a pipe. V6 doesn't special-case
it in any way, but it sounds as if other systems do.
What V6 does (to complete the list) is grow the temporary file being used to
buffer the pipe contents up to a certain maximum size, …
[View More]whereupon it halts the
writer, and waits for the reader to catch up - at which point it truncates
the file, and adjusts the read and write pointers back to 0. So fstat() on
V6, which doesn't special-case pipes in any way for fstat(), apparently
returns 'waiting_to_be_read' plus 'already_read'.
>>> xv6 has fstat() but returns an error if the file descriptor isn't
>>> associated with an i-node.
>> ?? All pipe file descriptors should have an inode?
To answer my own question, after a quick look at the Xv6 sources (on my
desktop ;-); it turns out that Xv6 handles pipes completely differently;
instead of borrowing an inode, they have special 'pipe' structures. Hence the
error return in fstat() on Xv6. (That difference also limits the amount of
buffered data in a pipe to 512 bytes. So don't expect high throughput from a
pipe on Xv6! :-)
So I guess you get to pick which semantics you want fstat() on a pipe to have
there: V6's, V7's (see below), or something else! :-)
> 7th Ed seems to return the amount of free space in the pipe, if I read
> the code correctly:
I'm not sure of that (see below), but I think it would make more sense to
return the amount of un-read data (which is what I think it does do), as the
closest semantics to fstat() on a file.
It might also make sense to return the amount of free space (to a writer), and
the amount of data available to read (to a reader), since those are the
numbers users will care about. (Although then fstat() on the write side of a
pipe will have semantics which are inconsistent with fstat() on files. And if
the user code knows the maximum amount of buffering in a pipe, it could work
out the available write space from that, and the amount currently un-read.)
> fstat()
> {
> ...
> /* Call stat1() with the current offset in the pipe */
> stat1(fp->f_inode, uap->sb, fp->f_flag&FPIPE? fp->f_un.f_offset: 0);
> }
> stat1()
> {
> ...
> ds.st_size = ip->i_size - pipeadj;
I'm too lazy to go read the code (even though I already have it :-), but V7
seems to usually be very similar to V6. So, what I suspect this code does is
pass the expression:
((fp->f_flag & FPIPE) ? fp->f_un.f_offset : 0)
as 'pipeadj' (to account for the amount that's already been read), and then
returns (ip->i_size - pipeadj), i.e. the amount remaining un-read, as the
size.
Noel
[View Less]
> From: Warren Toomey
> I'm trying to find out what fstat(2) returns when the file descriptor
> is a pipe.
In V6, it returns information about the file (inode) used as a temporary
storage area for data which has been written into the pipe, but not yet read;
i.e. it's an un-named file with a length which varies between 0 and 4KB.
> xv6 has fstat() but returns an error if the file descriptor isn't
> associated with an i-node.
?? All pipe file descriptors should …
[View More]have an inode?
Noel
[View Less]
Hi all, I'm working on a Unix-related project, and I thought I'd ask if
anybody here might help.
There's a pared-down Unix-like system, xv6, which is inspired by 6th Edition
Unix and the Lions Commentary. Its purpose is to teach OS principles.
The website and book are here:
https://pdos.csail.mit.edu/6.828/2014/xv6.htmlhttps://pdos.csail.mit.edu/6.828/2014/xv6/book-rev8.pdf
Unfortunately, while the kernel is nice, they don't provide much of
a run-time environment, so it feels too much of a …
[View More]toy to use. I had the
idea of porting a small set of libraries and commands over to get it to
the point where it feels a bit like 7th Edition.
I've made a start by using the Minix 2.0 libraries and commands, see
https://github.com/DoctorWkt/xv6-minix2 and the NOTES file. I now realise
that bringing up a libc plus associated commands will involve a fair bit of
work.
So, if anybody is interested in helping, let me know.
Thanks in advance, Warren
[View Less]
Dave Horsfall:
Not Henry Spencer, perchance?
=====
Since the Canadian in question had been working in the US since
1964 or so, he must by now be pushing 70 years old.
I haven't seen Henry for some years, but I don't think he has
aged that much.
Norman Wilson
Toronto ON
> Date: Sat, 30 Jul 2016 15:30:36 +0000
> From: Michael Kjörling <michael(a)kjorling.se>
> To: tuhs(a)tuhs.org
> Subject: Re: [TUHS] History repeating itself
> Message-ID: <20160730153036.GI3375(a)yeono.kjorling.se>
> Content-Type: text/plain; charset=utf-8
>
> On 30 Jul 2016 10:15 -0400, from cowan(a)mercury.ccil.org (John Cowan):
>>> Who needs FedEx?
>>
>> Well, latency counts for something too, as does radius: if I want to
>> …
[View More]send bulk data from New York to London (a very normal thing to do),
>> your station wagon isn't going to count for much.
>
> You could, however, get an economy class flight ticket and load up
> your suitcase with either HDDs or SDXCs (I suspect SDXCs would be
> better per amount of data from the perspective of both volume and
> weight, and would take better to handling). Given FedEx's prices,
> _once you have the infrastructure set up_ (which you'll need whether
> you have someone travel with the media, by air or by stationwagon, or
> FedEx it), that _might_ even compare favorably in terms of bytes
> transferred per second per dollar. (Now that's a measurement of
> throughput I don't think I've seen before; B/s/$.) Of course, you'd
> need someone who can babysit the suitcase, which potentially adds to
> the cost, but the stationwagon traditionally hasn't been self-driving
> either, and most of a transatlantic flight isn't active time on part
> of the person travelling with the suitcase so you could go with an
> overnight flight and allow the person to sleep.
>
> If you want to reduce the risk of the bag getting handled roughly or
> lost in handling, reduce the above to carry-on luggage; it will still
> provide a quite respectable throughput.
>
> ... ...
>
> It might not be the absolute cheapest approach, but it seems rather
> hard to beat in terms of throughput per dollar for bulk data transfer,
> especially if you already have someone who would travel anyway and can
> be convinced to take a company-approved suitcase in return for having
> their ticket paid for.
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
> “People who think they know everything really annoy
> those of us who know we don’t.” (Bjarne Stroustrup)
>
To setup the 'infrastructure might be the tricky part. Many years ago
I flew from Montreal to Amsterdam and had two stacks of 5-1/4"
diskettes with me. No papers, confiscated in Amsterdam.
Cheers,
Rudi
[View Less]
Hi folks,
My root partition for Unix v6 is almost full and /dev/rk0 only has 83 blocks.
The trouble is I wanted to compile bc.y and I think it needs around
300 blocks of temporary space. I was wondering if there was a way to
set up Unix v6 so that it could use one of the other drives for tmp
space. I tried to set up a link using ln but it seems I can't link
across filesystems.
The exact error is "26: Intermediate file error".
I managed to rearrange things so that /dev/rk0 had over 300 …
[View More]blocks of
free space and it fixed the problem, but I'm curious if there was
another solution.
Mark
[View Less]
